Ontology for Information Systems (O4IS) Design Methodology Conceptualizing, Designing and Representing Domain Ontologies

Home , Applied ontology, Computability, Conceptual model, Deborah McGuinness, Formal ontology, Information access

Vandana Kabilan

October 2007.

A Dissertation submitted to The Royal Institute of Technology in partial fullﬁllment of the requirements for the degree of Doctor of Technology .

The Royal Institute of Technology School of Information and Communication Technology Department of Computer and Systems Sciences IV

DSV Report Series No. 07–013 ISBN 978–91–7178–752–1 ISSN 1101–8526 ISRN SU–KTH/DSV/R– –07/13– –SE V

All knowledge that the world has ever received comes from the mind; the inﬁnite library of the universe is in our own mind. – Swami Vivekananda. (1863 – 1902) Indian spiritual philosopher.

The whole of science is nothing more than a reﬁnement of everyday thinking. – Albert Einstein (1879 – 1955) German-Swiss-U.S. scientist.

Science is a mechanism, a way of trying to improve your knowledge of nature. It’s a system for testing your thoughts against the universe, and seeing whether they match. – Isaac Asimov. (1920 – 1992) Russian-U.S. science-ﬁction author.

VII

Dedicated to the three KAs of my life: Kabilan, Rithika and Kavin.

Abstract. Globalization has opened new frontiers for business enterprises and human communication. There is an information explosion that necessitates huge amounts of information to be speedily processed and acted upon. Information Systems aim to facilitate human decision-making by retrieving context-sensitive information, making implicit knowledge explicit and to reuse the knowledge that has already been discovered. A possible answer to meet these goals is the use of Ontology. Ontology has been studied for a long time in the fields of AI, Logic and Linguistics. Cur- rent state-of-the art research in Information Systems has focused on the use of ontologies. However, there remain many obstacles for the practical and commercial use of ontologies for Information Systems. One such obstacle is that current Information System designers lack the know-how to successfully design an ontology. Current ontology design methodologies are difficult to use by Information Systems designers having little theoretical knowledge of ontology modeling. Another issue is that business enterprises mostly function in the social domain where there are complex underlying semantics and pragmatics involved. This research tries to solve some of these issues by proposing the Ontology for Information Systems (O4IS) Design Methodology for the design of ontologies for Information Systems. The research also proposes a Unified Semantic Procedural Pragmatic Design for explicit conceptualization of the semantics and pragmatics of a domain. We further propose a set of Semantic Analysis Representations as conceptual analysis patterns for semantic relationship identification. We also put forward the Dual Conceptual Representation so that the designed ontology is understandable by both humans and machines. Finally, a logical architecture for domain ontology design called the Multi-Tier Domain Ontology Architecture is proposed. We follow the design science in Information Systems research methodology. The proposed solutions are demonstrated through two case studies carried out in different domains. The first case study is that of business contract knowledge management, which focuses on the analysis of contractual obligations, their fulfillment via the performance of business actions, and the deduction of a contract compliant workflow model. The second case study relates to military operations simulations and modeling. The emphasis in this case study is to analyze, model and represent the domain knowledge as a re-usable resource to be used in a number of modeling and simulation applications.

Acknowledgement. It has been an enlightening journey into unknown frontiers, learning to solve new challenges, and ﬁnding more pieces of knowledge scattered along the way. But it would not have been possible, if not for the gentle steering and supportive guidance of my supervisor, Prof. Paul Johannesson. I thank – Paul; For being an quintessential supervisor who like a compass activates the magnets of curiosity, knowledge and wisdom. I thank all my colleagues at DSV – Maria, Jelena, Birger, Hercules and everyone else at SYSLAB; For being such excellent listeners, contributors and critics of my theories. I also acknowledge my colleagues at the Swedish Defence Research Agency – Vahid, Mar- ianela and Pernilla; For giving me the opportunity to be a part of their team and for the countless hours of brainstorming. I acknowledge all the wonderful researchers with whom I have had the opportunity to meet and exchange ideas. I specially thank Hans Weigand for his collaboration and constructive criticisms. Last, but not the least, this research would never have become a reality, without the support and motivation provided by my family – Mama and Athai; For your constant inspiration and motivation. Mom and Dad; For providing me with the best possible start to life that I could have ever wished for. Priya; For the being the perfect sister and professional proof-reader. Special thanks to my children Rithika and Kavin whose innocent smiles wipe away all exhaustion at the end of each tiring day. Finally, I owe this PhD to the one person who has believed in me always, pushed me harder, to reach higher – my best friend, my love and husband, Kabilan. Thank you for truly shining like the North Star, eternally constant without a ﬂicker.

Contents

1 Introduction ...... 1 1.1 Research Fields ...... 1 1.1.1 Information Systems ...... 2 1.1.2 Ontologies for Information Systems ...... 3 1.1.3 Conceptual Modeling and Ontology ...... 5 1.2 Research Domain ...... 7 1.3 Research Motivation: Information systems need ontology ...... 7 1.4 Research Problems ...... 9 1.5 Research Questions ...... 12 1.6 Goal...... 13 1.7 Purpose ...... 15 1.8 Scope ...... 15 1.9 Research Methodology ...... 15 1.10 Research Evaluation Criteria ...... 18 1.11 Case Studies ...... 19 1.12 Results ...... 20 1.13 Disposition ...... 24 1.14 Publications ...... 26

2 Knowledge Management and Information Systems ...... 31 2.1 The Data-Information-Knowledge-Wisdom Model ...... 31 2.2 Information Systems ...... 33 2.2.1 Knowledge Base Versus Database Information Systems...... 34 2.2.2 Knowledge Bases and Knowledge Base Systems ...... 35 2.3 Knowledge Management ...... 36 2.3.1 Knowledge Representation ...... 38 2.3.2 Different Roles of Knowledge Representation ...... 38 2.4 Relevance of Chapter ...... 40 XIV Contents

3 Ontology and Information Systems ...... 41 3.1 Ontology ...... 41 3.2 Uses of Ontologies ...... 44 3.3 Ontology – A Historical Background ...... 45 3.3.1 From Philosophy, AI and Logic ...... 45 3.3.2 From Linguistics to Information Systems ...... 47 3.3.3 From Knowledge Management to Information Systems ...... 48 3.3.4 What Information Systems can learn from Philosophical Ontology ...... 50 3.4 Ontology Types...... 52 3.5 Ontology Architectures ...... 53 3.6 Ontology Design Principles ...... 54 3.7 Ontology Development Approaches ...... 54 3.8 Ontology Design Methodologies ...... 56 3.8.1 Uschold and Gruninger’s Skeletal Method ...... 57 3.8.2 Gruninger and Fox Method ...... 57 3.8.3 Noy and McGuinness Method ...... 59 3.8.4 UPON...... 61 3.8.5 METHONTOLOGY ...... 62 3.8.6 Conceptualization in Methontology ...... 64 3.9 Relevance of Chapter ...... 65

4 Conceptual Modeling ...... 67 4.1 Conceptual Model ...... 68 4.2 Conceptual Modeling Methods ...... 69 4.2.1 ER Modeling Revisited ...... 71 4.2.2 Conceptual Graphs ...... 73 4.3 Intensional and Extensional Conceptual Modeling ...... 74 4.3.1 Conceptual Modeling Languages...... 75 4.4 Using Conceptual Modeling for Ontology Modeling...... 75 4.5 Conceptual Modeling Patterns ...... 77 4.5.1 Design Patterns ...... 78 4.6 Procedural and Behavior Representation Languages ...... 82 4.7 Relevance of Chapter ...... 86

5 Ontology for Information Systems Design Methodology ...... 89 5.1 Requirements on O4IS Design Methodology ...... 92 5.2 Introducing the O4IS Design Methodology ...... 93 5.2.1 Template for describing the O4IS Design Methodology ...... 95 5.2.2 G1: Establish the scope of the domain ...... 95 Contents XV

5.2.3 G2: Establish the targeted users, applications, and functional requirements ...... 96 5.2.4 G3: Choose ontology architecture: physical and logical ...... 98 5.2.5 G4: Choose ontology development approach ...... 99 5.2.6 G5: Choose level of ontology representation ...... 100 5.2.7 G6: Choose knowledge acquisition methods and tools ...... 101 5.2.8 G7: Knowledge analysis - conceptualize the domain ontology . 102 5.2.9 G8: Knowledge representation - implement the domain ontology ...... 102 5.2.10 G9: Evaluate, assess and verify the domain ontology ...... 103 5.2.11 G10: Use, maintain and manage the domain ontology ...... 104 5.3 Multi-tiered Domain Ontology Architecture ...... 105 5.3.1 Advantages of the Multi-tier Domain Ontology Architecture . . 107 5.4 Dual Conceptual Representation ...... 108 5.4.1 UML for Conceptual Modeling and Ontology Representation . 110

6 Uniﬁed Semantic Procedural Pragmatic Design ...... 113 6.1 Semantics, Procedures and Pragmatics ...... 115 6.2 Introducing the USP2 Design ...... 117 6.3 Verb Phrase Ontology ...... 119 6.4 Performative Verb Ontology ...... 122 6.5 Semantic Analysis Representations: Discovering Semantic Relationships ...... 126 6.5.1 Structural Relationships ...... 127 6.5.2 Functional Relationships ...... 127 6.5.3 Temporal Relationships ...... 129 6.5.4 Deontic Analysis Model: Deontic Relationships ...... 131 6.5.5 Nested or Complex Deontic Proposition ...... 135 6.5.6 ECA Rule Ontology: Prescriptive Relationships ...... 140 6.6 Semantic Concept View ...... 143 6.6.1 Design Guidelines for the Semantic Concept View ...... 144 6.7 Procedural Concept View ...... 156 6.7.1 Design Guidelines for the Procedural Concept View ...... 157 6.8 Pragmatic Concept View ...... 161 6.8.1 Design Guidelines for the Pragmatic Concept View ...... 163

7 Case Study I: The Business Contract Knowledge Management Project . 167 7.1 Case Study I Background ...... 168 7.2 Research Issues in Business Contract Knowledge Management ...... 171 7.3 Objectives for Case Study I ...... 172 7.4 Related Research for Business Contracts ...... 173 XVI Contents

7.5 Contract Management ...... 174 7.5.1 Document Centric Approach ...... 174 7.5.2 Process Centric Approach using Deontic Logic ...... 175 7.5.3 Normative Approach using Subjective and Deontic Logic . . . . . 176 7.5.4 Standardization Approach using Courteous Logic Programs . . 177 7.5.5 Communicative Approach using FLBC ...... 177 7.5.6 Enterprise Systems Approach ...... 178 7.5.7 Workflow Management Approach ...... 179 7.6 Multi Tiered Contract Ontology ...... 180 7.7 Using O4IS Design Methodology and USP2 Design ...... 180 7.8 Multi Tier Contract Ontology: Semantic Concept View ...... 183 7.9 Upper Level Core Contract Ontology ...... 184 7.9.1 Basic Concepts ...... 185 7.9.2 Contract Obligation Analysis: Pragmatic Concepts Analyzed . . 188 7.9.3 Obligation Types ...... 188 7.9.4 Business Contract Obligation States ...... 191 7.10 Specific Domain Level Contract Ontology ...... 196 7.11 Template Level Contract Ontology ...... 201 7.12 Deducing Contract Workflow Model: The Procedural Concept View . . 203 7.12.1 Contract Workflow Model ...... 203 7.12.2 CWM Methodology ...... 205 7.12.3 Detailed CWM Methodology ...... 206 7.12.4 Using BPMN to model CWMs ...... 214 7.12.5 CWM-BPMN Transformation Patterns ...... 215 7.13 Uses of MTCO and CWM ...... 224 7.13.1 Alignment of Contract to Business Process Models ...... 224 7.13.2 Contract Execution Monitoring ...... 225 7.13.3 Exception handling of Process Patterns: Analyzing Prescriptive Behavior ...... 225 7.13.4 Business Contract Risk Assessment ...... 227 7.14 Case Study I: Discussion of Results ...... 229 7.14.1 Summary of Case Study Contributions ...... 230

8 Case Study II: The Defence Conceptual Modeling Framework Project . 233 8.1 Case Study II Background...... 234 8.1.1 DCMF Project Goals ...... 235 8.1.2 DCMF Project Objectives ...... 235 8.2 Functional Requirements of the DCMF Project ...... 235 8.3 The DCMF Process ...... 237 8.4 Role of Ontology in DCMF ...... 238 Contents XVII

8.5 Using the O4IS Design Methodology and USP2 Design ...... 239 8.6 Defence Conceptual Modeling Framework- Ontology Suite ...... 242 8.6.1 SUMO as the Upper Ontology ...... 242 8.6.2 JC3IEDM as the Middle Military Domain Ontology ...... 244 8.7 Customizing Semantic Analysis Representations for Military Scenarios 248 8.7.1 Global Context ECA Rule - Prescriptive Relationships ...... 249 8.7.2 Military Behavior Analysis- ECA Rule Ontology ...... 251 8.7.3 Global Context: Structural Relationships ...... 257 8.8 Case Scenarios ...... 261 8.8.1 Scenario 1: The Kosovo Arms Smuggling Scenario ...... 261 8.8.2 Scenario 2: The Viking Shield Example: Lord Barkan Hostage Simulation ...... 267 8.8.3 Scenario 3: The Moscow Theater Hostage Crisis ...... 272 8.8.4 Scenario Viewer- application for Knowledge Use ...... 274 8.9 Case Study Results and Evaluations ...... 274

9 Discussion of Results ...... 277 9.1 Assessing the O4IS Design Methodology ...... 277 9.1.1 Surveyed Ontology Methodologies: A Recap ...... 277 9.1.2 Requirements Revisited ...... 279 9.2 Advantages of O4IS Design Methodology ...... 280 9.2.1 O4IS Design Methodology useful in all ontology building situations ...... 280 9.2.2 O4IS Design methodology proposes Dual Conceptual Representation ...... 281 9.2.3 O4IS Design Methodology considers functional requirements of application purpose ...... 281 9.3 Evaluating USP2 Design and the Semantic Analysis Representations . 284 9.4 Summary of Results ...... 285

10 Conclusions ...... 289 10.1 Problem Identiﬁcation and Motivation ...... 289 10.2 Objectives for a solution ...... 290 10.3 Design and Development ...... 291 10.4 Demonstration ...... 292 10.5 Evaluation ...... 292 10.6 Communication ...... 293 10.7 Open Issues and Future Work ...... 293 10.8 Conclusion ...... 294

References ...... 297 XVIII Contents

A Appendix ...... 309 A.1 INCOTERMS: Delivery Patterns for Sale of Goods ...... 309 A.2 Sample Contract Analysis ...... 316 A.2.1 Phase 1: Contract Type Identification ...... 316 A.2.2 Phase 2: Contract Instance MetaData ...... 316 A.2.3 Phase 3: Obligation Performance Events Identification ...... 316 A.2.4 Phase 4: Obligation, Performance, Non-Performance Interrelationships ...... 319 A.2.5 Phase 5: Optional mapping to existing Business Process flows. 323 A.2.6 Phase 6: Contract Workflow Model for sample contract ...... 324 A.3 Sample Contract...... 326 List of Figures

1.1 Information System Components ...... 3 1.2 Ontologies for IS and Ontologies of IS ...... 4 1.3 Conceptual Modeling Framework proposed by Wand ...... 5 1.4 Research Domains ...... 6 1.5 Current Situation of Ontology Design and Use in Information Systems: Based on MITRE Report ...... 10 1.6 Design Science Research Process Model ...... 17 1.7 The Proposed Design Methodology...... 21 1.8 Thesis Disposition ...... 25

3.1 Ontology Architecture proposed by Guarino ...... 53 3.2 Illustration for Top Down Development Approach ...... 55 3.3 Motivation for using Middle-Out Approach ...... 56 3.4 Gruninger and Fox Design Methodology ...... 58 3.5 UPON...... 61 3.6 METHONTOLOGY: Constituent activities and their states ...... 63 3.7 Intermediate conceptualizations in METHONTOLOGY ...... 64

4.1 Human Knowledge from Different Perspectives ...... 72 4.2 Basic DFD Notations ...... 83 4.3 Basic EPC Diagram Notations ...... 83 4.4 Basic UML Activity Diagram Notations ...... 84 4.5 Basic Petrinet Notations ...... 85 4.6 Basic BPMN Notations ...... 85

5.1 Chapter Disposition ...... 91 5.2 The Ontology for Information Systems Design Methodology ...... 94 5.3 Establishing Domain Scope...... 96 5.4 Establish the Applications and Users of the Domain...... 97 XX List of Figures

5.5 Types of Physical Architecture for Ontology ...... 98 5.6 Multi-tiered Domain Ontology Architecture ...... 99 5.7 Dual Conceptual Representation for Domain Ontology ...... 100 5.8 Moving from Generic to Speciﬁc Domain Conceptualization ...... 106 5.9 Example for Multi-Tier Ontology ...... 106

6.1 Disposition of Chapter: USP2 Design ...... 115 6.2 Unified Semantic Procedural Pragmatic Perspectives ...... 117 6.3 Semantics-Procedures-Pragmatics Domain ...... 119 6.4 Semantic Relationships: Classification Levels ...... 120 6.5 Status primitives from Verb Phrase Ontology ...... 121 6.6 Interaction primitives from Verb Phrase Ontology ...... 122 6.7 Performative Verb Ontology ...... 125 6.8 Temporal Relationships for Closed Intervals ...... 130 6.9 Temporal Relationships for Open Intervals ...... 131 6.10 Deontic Analysis Model ...... 133 6.11 Basic Deontic Proposition ...... 137 6.12 Nested Deontic Proposition ...... 138 6.13 Conditional Deontic Proposition ...... 139 6.14 ECA Rule Ontology ...... 141 6.15 ECA Rule Ontology: An Illustrative Example ...... 142 6.16 Identifying Concepts and Structures ...... 149 6.17 Extending Concepts ...... 150 6.18 Extending the Structural Relationships ...... 151 6.19 Adding Semantic Relations ...... 152 6.20 Ontology Implementation in Protégé Ontology Editor...... 156 6.21 Procedural Concept View: Car Rental Illustration ...... 158 6.22 Procedural Concept View: Extended Car Rental Scenario ...... 160 6.23 Pragmatic Concept View Car Rental Illustration ...... 165

7.1 Case Study I: Disposition ...... 167 7.2 Three Perspectives of Business Contract Domain ...... 169 7.3 Lifecycle of a Business Contract...... 175 7.4 Multi-leveled Communication Patterns ...... 178 7.5 Multi Tiered Contract Ontology...... 183 7.6 Upper Level Core Contract Ontology: Overview ...... 185 7.7 Upper Level Core Contract Ontology: A detailed Semantic Concept View...... 187 7.8 Performance Event Types ...... 189 7.9 Business Contract Obligation Types ...... 190 7.10 Business Contract Obligation States: Overview ...... 192 List of Figures XXI

7.11 Business Contract Obligation States: Detail ...... 193 7.12 Typical Contract Obligation Life Cycle ...... 195 7.13 Extract from Sale of Goods Contract showing expanded view for Buyer’s Obligation to Pay ...... 197 7.14 Extract from a Seller’s Obligation to Deliver and its Fullfillment/Unfullfillment ...... 199 7.15 Obligation to Deliver and Related Rights ...... 200 7.16 Sample Template Level Contract Ontology Model for Sale of Motor Vehicle...... 202 7.17 Sample Template Level Contract Ontology Model for Sale of Boats . . . 202 7.18 A Sample Contract Workflow Model using BPMN ...... 218 7.19 Pattern 3: Contract Obligation State Changes ...... 220 7.20 Pattern 4 and Pattern 5: Contract Performance Event Sequences and Simultaneous Processing ...... 221 7.21 Pattern 7: Exclusive Processing ...... 223 7.22 Pattern 8: Remedial Options ...... 224

8.1 Case Study II- Chapter Disposition ...... 233 8.2 Defence Conceptual Modeling Framework-Ontology Suite ...... 242 8.3 The Top Level Concepts in SUMO ...... 243 8.4 Main Concepts of DCMF-O: Adapted JC3IEDM ...... 246 8.5 Example of mapping 5Ws and the DCMFO ...... 250 8.6 5Ws-What mapped to DCMFO ...... 250 8.7 5Ws-Why mapped to DCMFO ...... 250 8.8 5Ws-When mapped to DCMFO ...... 251 8.9 Illustration of a Rule of Engagement analyzed using ECA Rule Ontology252 8.10 ECA Rule Ontology implemented in Prot´eg´e...... 255 8.11 Illustration of ECA Rule Ontology enriched with WORDNET ...... 256 8.12 MUST Kosovo Arms Smuggling Scenario ...... 262 8.13 Procedural Concept View: using CWM ...... 265 8.14 Pragmatic Concept View: using DAM ...... 266 8.15 Lord Barkan Hostage Scenario ...... 268 8.16 Lord Barkan Hostage Scenario: Functional Relations ...... 269 8.17 Lord Barkan Hostage Scenario:Prescriptive Behavior Analysis ...... 270 8.18 Lord Barkan Hostage Scenario: Scenario Viewer ...... 271 8.19 Moscow Theater Hostage Scenario: Military Operation ...... 273

A.1 INCOTERMS:Obligation to Exchange Goods ...... 310 A.2 Overview of common features of the INCOTERMS delivery patterns . . 313 A.3 INCOTERMS:Obligation to Exchange Goods ...... 314 XXII List of Figures

A.4 Ex Works: A typical case scenario for contract execution between seller and buyer ...... 315 A.5 Obligation and Performance Events in Time Ordered Sequence ...... 323 A.6 Deduced Contract Workﬂow Model using EPC Diagram ...... 325 List of Tables

2.1 Deﬁnitions of Information Systems ...... 34

6.1 Examples of Performative Verbs ...... 123 6.2 Structural Relationship Patterns ...... 127 6.3 Functional Relationship Patterns ...... 128 6.4 Action-Action Functional Relationships ...... 128 6.5 Pragmatic Relationships from Storey’s Verb Phrase Ontology...... 162

8.1 Sample Rules of Engagements ...... 253 8.2 Extract of Rules analyzed with only 5Ws ...... 253 8.3 Extract of Rules analyzed with ECA Rule Ontology ...... 254 8.4 Actor/Role-verb-Actor/role Structural Relationships ...... 258 8.5 Actor/Role-verb-Action Structural Relationships ...... 259 8.6 Entity-verb-Entity Structural Relationships ...... 260 8.7 Extract from Kosovo Scenario ...... 261 8.8 Semantic Analysis Extract for Kosovo Scenario ...... 263 8.9 Extract from Lord Barkan Hostage Scenario ...... 267

9.1 Comparison of Ontology Development Methodologies ...... 283

A.1 Extract from distribution of obligations in Ex-Works INCOTERMS delivery patterns ...... 312 A.2 Phase2- MetaData from Given Contract Example ...... 317 A.3 Phase 3- List of Obligations ...... 317 A.4 Phase 3- Obligation Owner and Ownee ...... 318 A.5 Phase 3- Obligations Summarized ...... 319 A.6 Phase 4- Deduced Performance Activities ...... 320 A.7 Phase 4- Seller and Buyer’s Obligations ...... 321 A.8 Phase 4- Buyer and Seller’s Performances: In Temporal Order ...... 322

O 1

Introduction

Ontology has its origin in philosophy, and since then it has played a vital role in the realm of AI (Artificial Intelligence), Linguistics and Logic. But of late, with the development of the Semantic Web (Hendler & Lassila 2001), ontologies have made their way into conceptual modeling and knowledge engineering fields as can be seen from the works of Uschold & Gruninger (1996) for enterprise modeling; Fernandez, Gomez-P´ érez, Sierra & Pazos (1999) in chemical ontology; Artale, Franconi, Guar- ino & Pazzi (1996) and Guarino (1998) in the field of knowledge representation and Bergamaschi, Castano, di Vimercati, Montanari & Vincini (1998) for information integration. But, what is ontology within Information Systems? Simply put it is nothing but a:

“speciﬁcation of a representational vocabulary for a shared domain of discourse– deﬁnitions of classes, relations, functions and other objects.” –Gruber (1993a).

A key use of ontology is to share information between people, databases and applications. Ontologies capture, represent and model domain knowledge in a machine- readable way so that it can be understood, interpreted and reused by humans and machines alike. Ontology as a knowledge representation is the key focus of this research.

1.1 Research Fields

Before proceeding further we would like to clarify some of the terms and concepts relevant to this research. There are three ﬁelds of research that are of concern to this research, namely:

• Information Systems Design. • Ontology: From philosophy, logic, linguistics, AI and ontology-based Information Systems. 2 1 Introduction

• Conceptual Modeling: From Knowledge Management to Information Systems.

We begin by exploring the deﬁnition of Information Systems.

1.1.1 Information Systems

For this research we uphold the deﬁnition(s) of Information Systems as given below (based on the proposal by Gupta (2000)):

• Information Systems is a field of study: Information systems is an interdisci- plinary field influenced by computer science, political science, psychology, operations research, linguistics, sociology, and organizational theory. • Information Systems is a type of artifact: Information systems are a broad class of computer software systems that provide information to aid organization decision making. In other words, an information system creates, processes, stores, and generates information to help individuals make meaningful decisions.

This research belongs primarily to the second category and we limit ourselves mainly to the information or domain knowledge analysis, representation and modeling. However, we analyze Information Systems as a ﬁeld of study to understand and explore the current state of the art research and related theories relevant to our research. As also pointed out by several other Information Systems practioners – an information system in an organization provides facts which are to be exploited by the human users of the system in order to function effectively. (We shall review some of these other viewpoints in chapter 2). Thus, we see that the human involvement with any information system cannot be removed. The dependency of an information system on the human actors may be reduced in some cases, like for example: human decision making may be supported using decision-support systems; complex analysis of market trends and customer satisfaction index may be computed automatically using data mining techniques; and knowledge bases or ontology based agents may monitor or broker electronic contracting. But, the ultimate control or the deciding factor still remains with the human counterpart who uses such Information Sys- tems. This is the demarcation line between an information system and an AI agent. O’Brien (2002), as depicted in ﬁgure 1.1, has observed that:

“People have relied on Information Systems to communicate with each other using a variety of physical devices (hardware), information processing instructions and procedures (software), communication channels (networks) and stored data (data resources) since the dawn of civilization.”

As seen in ﬁgure 1.1, data sources or knowledge resources are a key component of an information system. In this research, we focus on ontology as that knowledge 1.1 Research Fields 3

Fig. 1.1. Information System Components resource. There are several motivating reasons why Information Systems need ontology in today’s context as we discuss in section 1.3.

1.1.2 Ontologies for Information Systems

We shall discuss the background, definitions and related research of ontology in chapter 2. But for now, we aim to establish the background and context in which ontology is related to Information Systems. We agree with Fonseca’s (2006) view that ontology within information science has been explored in two meanings or contexts, namely: • Ontology of Information Systems: Ontologies that describe Information Sys- tems and can be used to create better modeling tools. Ontologies of Informa- tion Systems are mostly theory-focused. This type of ontology has been called reality-based(R-Ontology) ontology by Smith (2003a). Another example that may be cited is IEEE supported Information Flow Framework Foundation On- tology (Kent 2001) that aims to support interoperability between software and applications, as well as between the ontologies themselves. • Ontology for Information Systems: Ontologies that describe information that can be used in Information Systems, hence leading to improved functioning of Information Systems. Fonesca defines them as “pragmatically oriented ontologies” that are built by combining philosophical approach with pragmatic objectives. These belong to the epistemological ontology (E-Ontology) as proposed by Smith (2003a). Current information science research differs in terms of creation and use of ontologies for each of the two contexts as illustrated in figure 1.2. 4 1 Introduction

Fig. 1.2. Ontologies for IS and Ontologies of IS

Wand & Weber (2002) introduced a Conceptual Modeling Framework (see ﬁg- ure 1.3) in which they support the use of ontologies for validating and supporting conceptual modeling. They propose a contextual environment in which the Infor- mation Systems designers and users exist, called the conceptual modeling context. They use a set of constructs and rules that they term conceptual-modeling grammar along with a set of procedures, conceptual-modeling methods that can guide the In- formation Systems designer in building conceptual schemas, viz conceptual-modeling script. Wand & Weber (2004) state “our Information Systems will be only as good as our ontologies”. They hold the view that a good conceptual model is the key to a good information system. Therefore, their proposed conceptual modeling framework uses ontology of Information Systems to validate that the conceptual models are correct. Ontologies for Information Systems can be used at design time or at run time. In the design phase of Information Systems, ontologies can be useful in building the conceptual models for the information system, provide content and meaning to the information that is to be gathered. The ontology also acts as a common shared vocabulary amongst multiple Information Systems designers. Domain knowledge is thus reused. At run time, the same ontologies can support machine-to-machine 1.1 Research Fields 5

Fig. 1.3. Conceptual Modeling Framework proposed by Wand interoperability by acting as an ‘interlingua’ (Uschold & Gruninger 1996). Fonseca (2006) summarizes his discussion on ontologies of IS and ontologies for IS as:

R “Ontologies for IS in the context of ontology driven Information Systems are theories that describe and explain a domain....Ontology of IS provides us with tools (conceptual modeling grammar) to validate the models we use against reality, while Ontology for IS gives us the framework to validate the models themselves within the domain context of the particular information system being built.”

The above quote summarizes our understanding of the ontology concept within the Information Systems context as well. An ontology is a conceptual or mental model of a particular domain that is intended to be used for a speciﬁc purpose as a knowledge resource in an information system. We shall see more on ontology in chapter 3. We also accept that conceptual modeling is an integral part of an information systems’ design. However, we do not focus on the use of ontology for designing good conceptual models. Instead, as we shall see later, we propose the use of conceptual modeling to build good ontologies for use in Information Systems.

1.1.3 Conceptual Modeling and Ontology

So far, we have seen the relationship of ontologies and information systems, namely that of knowledge management. Knowledge in our context includes representation, modeling and use of collective information. For this research, conceptual modeling and conceptual models form the bridge between Information Systems and ontologies for Information Systems. We now draw attention to the field of semiotics introduced originally by Charles Sanders Pierce. There are three distinct fields of semiotics as introduced by Pierce and summarized by Kecheng (2000): syntactics (or syntax), 6 1 Introduction the study of signs, constructs, rules and grammar for composing complex signs; semantics, the study of meaning or relationship between the sign and what it refers to; and pragmatics, the study of purposeful use of signs like the behavior, communication and social norms. In the field of conceptual modeling of Information Systems, Boman, Johannesson, Janis & Wangler (1997) have further stressed upon the aim of conceptual modeling to construct a language for reasoning about some parts of reality. Figure 1.4 shows the relevance of conceptual modeling to this research.

Fig. 1.4. Research Domains

Naeve (2007) has listed a few deﬁnitions of key terms used in conceptual modeling, semiotics, linguistics as well as the object-oriented programming domain as:

• A concept is a representation of something that we experience or imagine and that we can apply to objects that we are aware of. • A description on the most important concepts and their relations within a speciﬁc problem is called a conceptual model of the domain. 1.3 Research Motivation: Information systems need ontology 7

• The deﬁnition of a concept describes its intention. Intensionality qualities a concept to express and delimit the meaning with respect to its surroundings. For example the concept ‘Mickey Mouse’ refers to a name of a creature limited to mouses. • The set of objects that exemplify a concept is called its extension. Extensionality refers to the actual denotation of the concept. For example, ‘Mickey Mouse’ refers to the Walt Disney cartoon character named Mickey Mouse. • Each member element of the extension set is called an instance of the concept.

The above set of deﬁnitions that describe concepts and a conceptual model are as relevant to the description of a domain ontology. We shall delve deeper in to the intensionality and extensionality and other aspects of conceptual models and ontologies in chapter 4. The proximity of conceptual modeling to ontology modeling makes it a keystone for this research. To round off our current discussion, we quote Fonseca (2006) as:

“Ontologies of IS and Ontologies for IS are the result of a long term research effort on conceptual modeling. Ontologies are a step forward to create better models.”

Bubenko (2007) aptly observes that the growing ‘ontological movement’: (i) seems to be unaware of the advances made decades earlier in conceptual modeling; (ii) the purpose and the process of developing an ontological model is not clear. We believe conceptual modeling to be the key field that can bridge and incorporate research developments from different fields as illustrated in figure 1.4.

1.2 Research Domain

We now summarize the domain and scope for this research as:

R This research focuses on the creation and use of ontologies for Information Systems. Our scope of interest revolves around how to create an ontology that is to be used for a speciﬁc objective in Information Systems.

Now that we have established the domain of interest and our primary scope, we shall motivate why an ontology is needed in Information Systems today.

1.3 Research Motivation: Information systems need ontology

The primary role of ontology within the Information Systems ﬁeld is its use as a knowledge source for human interpretation and understanding rather than for the 8 1 Introduction purposes of computational logic inferencing as in the case of AI. Currently the inferencing capability of ontology is being utilized in Information Systems. But, complete automation is not the ultimate goal since we would always have human involvement in an information system. However, emerging technologies like Semantic Web endeavor to make the web machine-readable, for providing the human consumers a more efﬁcient service, like context-aware information retrieval. Some other emerging factors that necessitate the use of ontology in Information Systems are discussed below:

1. Growing needs and technological advances. Information systems are designed to process data efﬁciently, speedily and accurately. Now with the onset of Se- mantic Web technologies, the shift from data processing to knowledge management is subtle yet inevitable. With this comes a shift in the way we visualize, model and represent information. Earlier, Information Systems were content with relational data models, then came the object-oriented concepts, and now we have aspect oriented programming and agile programming techniques. With the growing use of Internet and globalization, the quest and usage of knowledge is exponentially increasing. The amount of information that is made available far exceeds the capacity of any human processing or existing Information Sys- tems capability. To parse and understand this massive explosion of information is beyond the scope of any human users of traditional Information Systems. Information needs to be processed and represented at the knowledge level so that relevant information can be readily retrieved and understood by the human users. Information retrieval from the Internet is a growing need. Ontology is an accepted knowledge representation that can meet this need.

2. Changing market trends and users of Information Systems. The Times magazine (December 2006) has voted the Internet user as the most influential person of 2006. The Internet has become the medium of social communication, expressing opinions, conducting business, as well as entertainment and leisure for its human users. The advances in mobile technology, electronic gadgets have made the end user technology savvy. Everyone expects speedy, efficient service. For example, users are no longer satisfied by the keyword based or ranking algorithm based search engines like Google (GOOGLE search engine Web Resource). They want context aware or meaningful (semantic) information retrieval. Swoogle (Ding, Finn, Joshi, Peng, Scott Cost, Sachs, Reddivari & Doshi 2004) and Hakia (HAKIA: The search for meaning Web Resource) are examples of semantic search engines. The vision of Semantic Web is to make the information contained in the web pages parsable to electronic agents. Ontology is a key component of Tim Berners-Lee’s Semantic Web tower (2001). 1.4 Research Problems 9

3. Seamless and flexible interoperability needed between enterprises. Back- end office applications and traditional enterprise systems need to ‘interoperate’ with each other, with the Internet and so on. Rigidly coupled Enterprise Applica- tion Integration is a costly, time consuming and non-flexible solutions. Semantic interoperability is afforded by ontologies, and the role of ontology for enterprise interoperability is the subject of many ongoing research projects like the IST-INTEROP 1 project.

Following Ackoff’s (1989)’s Data-Information-Knowledge-Wisdom model (discussed in chapter 2), we know that information needs to be processed and collated with a better understanding to get knowledge. Information system applications, can no longer efﬁciently satisfy the need of the changing market, simply by processing chunks of data. They need to support higher level of reasoning and provide intelligent suggestions. Ontology, is one candidate, which is now being proposed as an answer to this quest. We will look closer at ontology and its concepts in chapter 3. But, for now, we focus on some of the contemporary issues regarding the use of ontology in Information Systems.

1.4 Research Problems

As we saw in the previous section, the changing needs for Information Systems require: (i) more expressive and computable knowledge representations, and not mere data models; (ii) better shared understanding amongst the human trading partners globally spread out; (iii) improved and easy interoperability between Infor- mation Systems. Ontology is one possible solution available to Information Systems. While academic and scientiﬁc research in this domain has been making progress, we see that ontology design and use in information system is still not commercially widespread. Below we list some of the reasons why ontology is not widely used in Information Systems:

1. Abstract Research not in tandem with applied research and Industry. We can see that ontology in Information System is a growing field. Though, as seen in the survey result in figure 1.5 most of the work is still in the zone of abstract research. MITRE (April 2006) also concludes that Semantic Web and Ontologies have not been embraced by mainstream industry as yet but that there are indications that it will gradually be incorporated. As per their review, the current technology is in the phase of ‘early commercialization’, as illustrated in figure 1.5 adapted from their report. But, a lot needs to be covered in order to promote the uptake of

1 Interoperability Research for Networked Enterprise Applications and Software, FP6 508011, www.interop-noe.org 10 1 Introduction

Fig. 1.5. Current Situation of Ontology Design and Use in Information Systems: Based on MITRE Report

ontology in commercial use. Efforts of standardization groups like the W3C 2 and the OMG 3, aims to bring ontology in to the applied research and commercial usage. This research is focused along the same lines. The slow uptake of ontology in applied research or in commercial use is not only due to lack of available tools for design, development and maintenance, but also because the Information Systems designer needs to be guided in making the transition from traditional systems engineering approach to the ontological design approach.

2. Ontology design does not cover all of the functional needs of Information Systems. As said before, typical Information Systems applications have targeted end users, with speciﬁc purpose. The domain knowledge to be captured in such cases involves not only descriptive deﬁnitions of objects and things but also the prescriptive behaviors and actions of these objects, as well as the constraints (rules) binding them. These aspects are represented in typical Information Sys- tems applications as constraints, rules and logic. Some of these concerns are separated using different logical, physical or conceptual layers (architecture) or using different representational or operational syntax.

2 World Wide Web Consortium, www.w3c.org 3 Object Management Group, www.omg.org 1.4 Research Problems 11

While the advantages of using ontology as a knowledge representation has been much discussed (Noy & Hafner Fall 1997), the need for imbibing some of the strategies and best practices from Information Systems design is still felt. As re- gards the modeling of prescriptive behavior or operational knowledge, which are domain concepts in themselves, current research(Grosof, Yannis & Chan (1999), Guarino (1998)) suggests the use of separate logic layer (using a rule language like RULEML 4, SWRL 5 etc). But we need to make the domain knowledge explicit, that includes the behavioral, business constraints and operational knowledge as well. That is, we need to be able to express these different perspectives of the domain in ontology as well.

3. Ontology design methodologies are not explicit enough and easy to adopt for IS Designers. Furthermore, ontology design and development is not a straightforward or easy to adopt practice for the inexperienced Information Sys- tems designer. Neither is it easy for the targeted users to comprehend, use and maintain such ontology-based Information Systems, given the lack of comprehensive front end tools and interfaces. Thus the Information Systems designer as well as the users need to be guided with directions on how he is expected to analyze, capture, represent, model and use ontology in the Information Systems applications.

4. Ontology design for Information Systems needs to capture and represent prescriptive behavior in addition to descriptive vocabulary. Many methodologies and approaches for the design and development of ontologies have been proposed like Uschold & Gruninger (1996), Gruninger & Fox (1995), Noy & McGuinness (2001), Fernandez, Asuncion Gomez-P´ érez & Juristo (1997) and De Nicola & Missikoff (2005) to name a few. We shall summarize and review these in chapter 2. However, we find many practical hurdles in applying any one of them constructively to the design of a particular domain ontology. In our research, we have focused on building ontology for different domains, having different targeted applications and users. We experienced that most of the current state-of-the art ontology design methodologies: • Do not prescribe sufficiently how to handle and merge the functional requirements of the information system. • Are useful for capturing the ‘static’ descriptive semantics only, that is they do not specifically address the pragmatics, and behavioral aspects. We shall see more about some of the state of the art ontology design methodologies in section 3.8. 4 Rule Mark-up Language 5 Semantic Web Rule Language 12 1 Introduction

• Overlap each other in some design phases but they are not individually comprehensive, that is dealing with all design oriented decisions that a designer needs to make - architecture, type, functional criteria, knowledge capture and analysis methods, representation and formalization methods and so forth. Most ontology design methodologies available today propose design phases to help build ontology from scratch, where no prior knowledge has been established. Though most of them advocate the reuse of existing knowledge, clear instruction on how such existing knowledge is missing. In some cases, reuse of existing ontologies of the same knowledge representation is possible. • Except METHONTOLOGY (Fernandez et al. 1997), few methods support gradual evolution and maintenance of ontology as well. The above mentioned design philosophies are useful for capturing the semantic vocabulary of the domain. But, it is not exhaustive or complete, as the implicit pragmatics is often not made explicit. It is left to the Information Systems designer to apply his human understanding and reasoning to make obvious the background context.

The above mentioned issues are some of the interests driving this research. These issues motivate our proposed ontology design methodology targeting Information Systems designers. This research focuses on the grey zone between science and technology – To make the transition from being an innovative scientific research theory (ontology) in to an acceptable, successful and useful technology. Apropos our earlier discussion on the two meanings of Information Systems, our research is a cross blend of both. It begins with Information Systems as a field of study incorporating approaches from philosophy, linguistics, logic and computer science. And the research ends in exploring how the designed artifacts (ontologies) may be used in an information system application. As Kuhn (1996) proposed – ‘extraordinary science’ would indeed affect paradigm shifts, but then by progressive practice of science, it should pass over into being ‘normal’ science. To improve the hypothesis, it’s the ‘puz- zle solving’ experiments which provide the test bed and boundaries for improving scientific theories. 6

1.5 Research Questions

Summarizing the key issues discussed in the previous section, we see:

• There is an exponential growth of information that Information Systems need to process.

6 Thomas Kuhn’s original version was published in 1962. The current readings are based on the 3rd edition from Chicago university press. 1.6 Goal 13

• There is a need for fostering shared understanding in this age of globalization and e-commerce. • There is a need for Information Systems to semantically interoperate with others across the world. • There is a need to understand the implicit semantics and pragmatic aspects of social domains.

In this context, we look at ontology as a possible candidate for solving the above needs. For this research an ontology in Information Systems is a conceptualization of extensional and intensional representations of domain concepts and their relationships. That is, for making the domain knowledge explicit we need to capture the semantics and pragmatics of the domain. This raises the issue – who should design and develop such a domain ontology? A trained ontologist would be a natural choice. However, we believe that it should be possible for even Information System designers to design at least parts of such a targeted domain ontology. Though we have seen numerous research illustrating the utility of ontologies in Information Systems, it is still unclear how domain ontologies may be practically used in Information Systems. Thus, the fundamental research questions that this thesis aims to address are:

1. How can the semantic and pragmatic aspects of social domains be represented as ontologies that are to be used in Information Systems? 2. How should domain ontologies (of social domains) be designed, considering the functional requirements of Information Systems, including design choices that an IS designer should make with regard to architecture, development strategy, representation language, and selection of tools? 3. For what purposes may an ontology of social domains designed for Information Systems be used?

1.6 Goal

To respond to the question how should the semantic and pragmatic aspects of social domains be represented, we delve into the ﬁeld of semiotics; syntax, semantics and pragmatics of knowledge representations, particularly emphasizing on the latter two aspects. To respond to the question how ontology of social domains should be designed, we need to study and analyze the current state of the art in ontology design methodologies, relevant literature from linguistics, AI, philosophy and Logic that help in analysis of extensional and intensional representations. Thereafter, we need a design methodology that describes explicitly how the different aspects of the domain 14 1 Introduction are to be represented. Finally, the proposed methodology should be simple enough for Information Systems designer (but a non-ontology expert) to adopt and follow. To answer the question of how ontology of social domains can be used we would need to use and demonstrate its utility in different domains, in different case studies having different purposes and users. Thus, our goals for this research may be summarized as:

• To propose a methodology for designing ontologies of social domains with a focus on their semantic and pragmatic aspects. • To demonstrate the usefulness of this methodology for designing ontologies that can be used as knowledge resources for designing and using Information Systems.

We clarify some of the terms used to define our research goal below: Methodology: Avison & Fitzgerald (1995) have defined an information system development methodology as: “ a collection of procedures, techniques, tools and documentation aids which help the systems developers in their efforts to implement a new information system. A methodology will consist of phases, themselves consisting of sub-phases, which will guide the systems developers in their choice of techniques that might be appropriate at each stage of the project and also help them to plan, manage, control and evaluate the Information Systems projects.” We adopt their definition as our objective and scope for the proposed methodology. Domain Ontologies: A layman’s definition of domain ontology maybe given as:

A domain ontology (or domain-speciﬁc ontology) models a speciﬁc domain, or part of the world. It represents the particular meanings of terms as they apply to that domain.

A more theoretical deﬁnition of a domain ontology has been given by Guar- ino (1995, 1998) as a partial explicit account of a conceptualization and a logical theory that describes the intended meaning of a logical language. A domain ontology is thus an intensional (intended meaning) conceptualization of particular domain knowledge. Guarino (1998) categorizes ontologies as top-level generic ontology, domain ontology specializing on terms from the generic ontology, task ontology and application ontology. We shall discus more on this in chapter 2. For this research, by domain ontology we mean an abstract model of a particular domain that captures, represents and models the implicit and explicit domain knowledge. We also limit ourselves to domains that involve social norms, behavior and prescriptions. Also, since we are interested in social domains, the human factor cannot be neglected. Hence conceptual representations that can be interpreted by humans is a predominant requirement. We do not delve into formal ontology, generic foundational ontologies or ontologies of Information Systems. 1.9 Research Methodology 15

Information System Applications: The proposed uses of the domain ontologies to be designed are visualized to have the same generic uses of ontology such as reuse, shared knowledge, making explicit implicit knowledge, interoperability across systems, communication and so forth. As such, we consider, shared common understanding between human users of the proposed domain ontologies as an application of ontology in Information Systems.

1.7 Purpose

The targeted users for the proposed methodology are the Information Systems (IS) designers and human end users for potential applications. In fact the designers, developers, business managers, decision makers and users of any information system today. The methodology aims to narrow the gap between abstract research, applied research and the commercial use of ontology in information system.

1.8 Scope

In the light of the research issues discussed above, we limit our analysis and foray into the realm of ontology design and modeling to the extent of knowledge capture and representation using conceptual models and expressing them in Web Ontology Language (OWL). As the primary targeted audience for this research are the IS designers, business managers and decision makers (human designers and users), we focus more on the knowledge capture and representation aspect than the formal encoding of ontology in machine-understandable format. In other words, we choose to investigate the expressive power of ontology language, design methodology rather than its computability (as supported by formal ontology speciﬁcations like KIF 7). While the proposed conceptual models and proof-of-concept ontologies using OWL are computable, accuracy and comprehensiveness have not been within the scope of this research.

1.9 Research Methodology

As with any research process, there needs to be a planned course of action, that is, a research methodology. Given the problem and design oriented research goals, we deem this to belong to the genre of design science research. As stated by Hevner, March, Park & Ram (2004) - There are two paradigms in Information Systems research - design science and behavioral science. Behavioral science paradigm devel- ops and veriﬁes theories that explain or predict human behavior or organization. 7 Knowledge Interchange Format 16 1 Introduction

Design science aims to improve or extend the human and organization capabilities by building new artifacts. As Hevner et al. (2004) say – “In the design science paradigm knowledge and understanding of a problem domain and its solution are achieved in the building and application of the designed artifact”. In this research, we strive to attain our stated goals through practical case studies. We analyze different domain areas for their specific research issues and thereafter, use existing state of the art literature and available ontology design methodologies to design, develop and build domain ontologies for each of the case studies. We agree with (Hevner et al. 2004) that design is both a process and a product. Our contribution in such context consists of both a design methodology (on how a given domain may be analyzed, captured and modeled as ontologies) and the proposed set of ontologies as artifacts. The ontologies are reusable in other future research or implementation purposes. Design processes may be ‘build’ and ‘evaluate’. Design artifacts may be ‘constructs’, ‘models’, ‘methods’ and ‘instantiations’. Artifacts are built to solve given research problems and their utility is therefore evaluated. Constructs are used as the language to define the problem and the solution proposed (Schon 1993). Models are used to represent the real world problem and to provide a better understanding. Methods are used to define the problems and how they may be addressed as well as how the models solving the identified problems may be built using the constructs defined. The difference between routine engineering solutions like building software applications to solve enterprise management issues and that of design science, is that, the former focuses on applying preexisting, and accepted theories and methods to build new artifacts. Whereas, design science focuses on using new or improved methods or theories to build artifacts for unsolved problems. In yet another related research, Peffers and Tuunanen (2006) introduce a conceptual process and mental model called the Design Science Research Process (DSRP) model. Our research methodology follows the six step (DSRP) Model as illustrated in figure 1.6 and summarized briefly as follows:

• Problem identification and motivation: Peffers et al. propose that the first step is to identify the research problem and justify its need for a solution. Thereafter, the problem definition is to be used to develop an artifact as a solution. The research has to motivate and convince the audience that the results are necessary, viable and credible. To achieve this, the research has to make use and demonstrate knowledge of the current state of the art and the relevance of the identified problem. • Objectives for solution: In the second step, the research must infer the objectives for the proposed solution to the identified problem. To quote Peffers - “The 1.9 Research Methodology 17 Design Science Research Process Model Fig. 1.6. 18 1 Introduction

objectives are to be based rationally on the identified problems and should lead to the development of new or improved artifacts.” • Design and development: The third step is the creation of the artifacts. Arti- facts may be models, methods, constructs, or instantiations. This step includes determining the functionality of the artifact and developing it using a theory. • Demonstration: Research should demonstrate the utility of the developed artifact. This may be done via experimentation, simulation, case study, proof or other means. The idea is to demonstrate how the artifact can be used to solve the identified problem. • Evaluation: Research should observe and measure how well the artifact solves the problem. It includes a comparison of the artifact to the original objectives set up. How far does the artifact fulfill the objectives? Other quantitative assessment may also be done. • Communication: Finally the research and its results are to be disseminated. The knowledge gained should be communicated to other scientific researchers, practicing professionals via publications in scientific channels, and other channels of dissemination.

We shall discuss the above mentioned research methodology and at the same time review our own research with respect to the DSRP in chapter 9. The problem identification and motivation has been carried out in this chapter. As has the overall objectives for the proposed solution been put forward. In chapters 5 and 6 we present the design and development of our proposed solutions. Chapters 7 and 8 demonstrate the use of the proposed solution through two different case studies. Evaluation is done through a discussion of results in chapter 9. Communication of the research has been done through scientific publications (see publication list under section 1.14). Our research methodology follows design science philosophies as proposed by Hevner et al. (2004) and Peffers, Tuunanen, Gengler, Rossi, Hui, Virtanen & Bragge (2006). Our research is problem-oriented with the goals and scope as described under sections 1.4 to 1.7. The design methodology is based on literature study, thereafter applying them on the targeted case scenarios iteratively till our objectives were fulfilled. We shall use the above mentioned guidelines as criteria to assess/validate our current research itself.

1.10 Research Evaluation Criteria

As stated earlier, the design science research guidelines form the ﬁrst level of evaluation criteria. We shall discuss and review our research via the seven guidelines proposed by Hevner et al. (2004), namely: 1.11 Case Studies 19

• Design as an Artifact: Must produce a viable artifact, method, model or an instantiation. • Problem Relevance: Requires creation of a technology based solution to a real world problem. • Design Evaluation: The artifact must be useful and hence must be evaluated for its utility, quality and efficacy. • Research Contributions: The artifact must be novel, using a new improved or innovative approach to solve the problem domain. The research contributions must be clear and verifiable. • Research Rigor: The artifact must be coherent, rigorously defined, internally consistent. Application of rigorous methods in the design and development process must be visible. • Design as a Search Process: The search for an effective artifact requires that available means and methods must have been utilized. • Communication of Research: Design science must be effectively communicated to technology oriented as well as management oriented audiences.

Thereafter, the results of the research are validated as per the evaluation and communication steps of the DSRP model as:

1. Peer review from other researchers in the same ﬁeld. This is achieved through joint research with other researchers, publishing scientiﬁc articles in appropriate circles and also reviews by domain experts and end users for proposed ontologies. 2. However, the main assessment of the usability,viability of the proposed methodology, is to be achieved by applying the same on different case studies, each relating to different domains, having different functional requirements, purposes, targeted users etc.

1.11 Case Studies

Following the design science research methodology, we need to test or evaluate the utility of our proposed methodology in the application contexts. For this purpose, we apply O4IS design methodology in two case studies chosen from different social domains as follows:

• The ﬁrst case study deals with ontology capturing the semantics and concepts of legal business contracts. Common shared knowledge from the cross domain of legal norms, regulations, legislatures and that from the enterprise and business value domains is expressed for Information Systems application purposes. The use for this ontology is for establishing a common model for understanding 20 1 Introduction

between humans and human-to-machine. Information systems applications ranging from interoperability of enterprise systems, modeling of contract compliant business process ﬂows are proposed. • The second case study delves into the domain of military modeling and simulation. The semantics and pragmatics of the military operations and procedures are to be captured in an ontology for generating military virtual simulations, reasoning and inferencing tools etc.

As seen, the two domains chosen differ not only in their semantics and pragmatics but also in regard to targeted users, purpose for the ontology, and have different functional requirements. The first case study was the first iteration for addressing the stated research goals. The focus in this phase was on the structural design and development of domain knowledge as ontology. Based on the experiences and feedback received on the outcome of this case study, refinements to the proposed guidelines were done. The second case study, thus, provides a base for more critical evaluations on the methods and approaches adopted. Hence the focus in the second case study has been more on the design methods and models for capturing the intensional aspects of ontology than on the denotation of the semantics (as in the first case).

1.12 Results

To fulfill the research goals stated in section 1.6 above, we propose an easy-to-follow design methodology targeting Information Systems designers to help them in their quest to build ontologies for Information Systems. The design methodology is aimed to answer the first goal namely – how ontologies for Information Systems may be developed. The proposed design methodology is called the Ontology for Information Systems (O4IS) design methodology. O4IS design methodology presents a stepwise design philosophy for ontology conceptualization but also contributes several other methods, constructs, approaches, and models as artifacts, as illustrated in figure 1.7. O4IS design methodology by itself is not much different from any other software design process. Hence, Information Systems designers should be familiar with the different steps therein. But the approaches, design methods, and patterns that are to be used as inputs in these steps are original contributions of this research. These are visualized to help the Information Systems designer in his modeling task while developing the ontology for Information Systems. At the same time, these act as helping aids to the final end user who shall use the ontology based information system. As illustrated in figure 1.3 and discussed earlier, our O4IS design methodology puts forward a conceptual modeling context (ontologies for IS), prescribes a conceptual modeling method (Unified Semantic Procedural and Pragmatic Design), provides sets of 1.12 Results 21

Fig. 1.7. The Proposed Design Methodology 22 1 Introduction conceptual modeling grammar (Semantic Analysis Representations) and shows the feasible transformation into conceptual modeling scripts (OWL formal ontology). We brieﬂy discuss an overview of O4IS design methodology and its related artifacts (as can be seen in ﬁgure 1.7):

• G1: Establish the scope of the domain: The domain (or universe of discourse as it is also known as) refers to the domain of interest which is to be captured in the ontology. The scope refers to the boundary or limitations that constrain the extent of the domain conceptualization. • G2: Establish the targeted users, applications, and functional requirements: Every information system is designed to provide a specific function for selected group of users. Thus, the functionality and the targeted audience guides the design features of Information Systems. • G3: Choose ontology architecture - physical and logical: In this step, we decide what kind of physical or logical architecture is suitable for our proposed domain ontology. For the logical architecture we propose a multiple layered architecture for the domain conceptualization. (Details in section 5.3) • G4: Choose ontology development approach: We choose the appropriate development approach that suits the particular domain and the requirements. The possible approaches are:- top down, bottom-up or middle-out. • G5: Choose level of ontology representation: We choose the appropriate level of abstraction and required representation formalism that satisfies the targeted use for the domain ontology. For human users and for shared understanding, it would be sufficient to represent the ontology as conceptual models. For semantic interoperability, context based information retrieval, we would need formal machine-readable language like Web Ontology Language (OWL). We propose that a Dual Conceptual Representation be followed even if a formal OWL representation is desired. Advantages and details of Dual Conceptual Representation shall be discussed in section 5.4. • G6: Choose knowledge acquisition methods and tools: We choose our tools and other methods for gathering the required domain knowledge. Guidelines G6 to G7 together comprise our main contribution, namely the Unified Semantic Procedural Pragmatic (USP2) Design for domain conceptualization. USP2 De- sign consists of (a) constructs (patterns, conceptual models and ontology) for the analysis of the domain called the Semantic Analysis Representations(SAR). The SARs help in the semantic analysis of different types of relationships including structural, functional, temporal, prescriptive and deontic; (b) guidelines and methods for performing this analysis using the above mentioned SARs. The USP2 Design and the included SARs are described in chapter 6. • G7: Knowledge analysis- conceptualize the domain ontology: Gathered information has to be analyzed and then conceptualized. The analyzed information is 1.12 Results 23

semantically represented using one or more perspectives of USP2 design, namely the Semantic Concept View, Procedural Concept View and the Pragmatic Concept View. • G8: Knowledge representation- implement the domain ontology: Conceptu- alized knowledge is to be represented in our chosen knowledge representation language or tool, as decided in G5. • G9: Evaluate, assess and verify the domain ontology: The designed ontology needs to be tested in the targeted application domain. The utility is to be assessed. The contents need to be veriﬁed with respect to the real world being modeled. • G10: Use, maintain and manage the ontology: The domain ontology cannot be forgotten once the development is completed. Like any other information system, it needs to be used, maintained, and managed. Continuous feedback will require successive iterations of the proposed O4IS design methodology.

The second goal in our research, that is, to investigate how social domain ontologies for Information Systems may be used, we have designed, developed and used ontologies in two different case studies. The case studies have been outlined in section 1.11. The case studies for the research using the proposed methodology, themselves contribute valuable results of this research such as:

• Case Study I– Multi Tier Contract Ontology: We shall discuss details in chapter 7. Some of the contributions from this case study may be listed as:- – Contract Conceptual Models: Declarative and prescriptive representations of a generic upper level contract ontology, a sale of goods contract type specific domain contract ontology, a number of template contract models, reusable delivery patterns from the INCOTERMS. – Contract Obligation State analysis: A deontic and performative analysis of the contract obligations with respect to their fulfillment via the execution of business activities. – Contract Workflow Methodology: A domain specific methodology for the extraction of the Procedural Concept View from a given business contract. This is called called a Contract Workflow Model(CWM). A set of workflow analysis based patterns for helping the designer in deducing the CWM is also proposed using BPMN (Business Process Modeling Notation). – Business Contract Risk Assessment methodology: Based on the MTCO and our obligation state analysis, we also propose a methodology for business contract risk assessment and evaluation. We provide a summary in section 7.13.4. The methodology itself may be referred to in our publication (Kabilan & Weigand 2006). 24 1 Introduction

– Contract-Business Process Alignment: In (Zdravkovic & Kabilan 2005a) we have proposed a method to align the internal business process models based on the deduced contract workflow models. • Case Study II – Defence Conceptual Modeling Framework: While Case study I has yielded artifacts and models, case study II has contributed to the theoretical formulations. It has provided us with a testing environment for our proposed O4IS design methodology and its constituent artifacts. Several new issues have been revealed leading to further refinement of our methodology. This is an ongoing project and work is still continuing on the ontology suite design. Details are presented in chapter 8. – DCMF-Ontology Suite: Consists of a set of ontologies which follow the multi- tier architecture. The Suggested Upper Merged Ontology (SUMO)(Niles & Pease 2001) is adopted as the upper ontology. A military standard data model with over 20,000 concepts is taken as the source for our specific domain ontology. A number of application specific ontologies have been developed. – ECA Rule Ontology: The prescriptive behavior of the Rule of Engagement doctrines have been analyzed and captured using our proposed SAR for prescriptive behavior.

1.13 Disposition

The rest of this thesis is structured as described in figure 1.8. Following the DSRP model (figure 1.6), we have begun this thesis document by the problem identification and motivation in the current chapter. To solve the identified problem we propose a design in chapters 5, and 6. Research rigor and current state of research in the area surrounding the identified problem is described in chapters 2, 3, and 4. So far we have been discussing the role of ontology in Information Systems. We have argued that the growing demands on the use of Information Systems necessitates that information is processed to a higher degree, more efficiently and faster. So, the question is – when does information become knowledge? To understand this, we begin our voyage into the theoretical background by investigating what is knowledge in chapter 2. Chapter 2 concludes by assessing the relationship between knowledge management and Information Systems. We have identified ontology as a choice to meet the identified current needs for information system (section 1.3). In chapter 3 we shall look closely at what is an ontology and how it can meet the identified needs. We shall also review some of the other state-of-the-art design methodologies for building ontologies for Information Systems. As we have said, conceptual modeling is a key part of Information Systems design. Conceptual models are also a vital component in the design of ontologies for 1.13 Disposition 25 information system (figure 1.3 and 1.1.2). Using conceptual modeling approaches is one of the key proposals in our O4IS, since, we visualize that such well known design approaches will enable the Information Systems designer in rapidly designing ontologies. Hence, we review some of the relevant literature and conceptual modeling approaches in chapter 4. Our first goal on how to design an ontology for Information Systems is answered in chapter 5, where we present our Ontology for Information Systems (O4IS) design methodology. We present a set of patterns for semantic relationships called Semantic Analysis Representations (SARs) as well as a novel domain perspective conceptualization via the Unified Semantic Procedural Pragmatic (USP2) Design is presented in chapter 6.

Chapter 1: Introduction

Related Research Chapter 2 : Chapter 3: KM, IS Design Ontology

Chapter 4 : Conceptual Modeling

Proposed Design Chapter 5: Ontology Chapter 6: for Information Unified Semantic Systems Design Procedural Pragmatic Methodology Design

Case Studies Chapter 8 : Defence Chapter 7: Multi Tier Conceptual Modeling Contract Ontology Framework: Ontology

Chapter 9: Discussion of Results

Chapter 10 : Conclusion

Fig. 1.8. Thesis Disposition 26 1 Introduction

So far, we have focused on the question of how an ontology suitable for use in an Information Systems application context can be designed and developed. In the next two chapters, chapter 7 and chapter 8 we look at two other issues of interest, namely:

• How can ontology be used in the Information Systems domain? Are they really useful? if so, in which contexts or applications can we use them? - To answer this we take up two case studies from different domains, having different applications, and the ontology results for these case studies are discussed in chapter 7 and chapter 8. • Is the proposed Ontology for Information Systems design methodology useful? Is the proposed USP2 Design useful for eliciting implicit domain knowledge? In what applications can such extracted information be used? - To answer these questions, we make use of the proposed domain ontologies in both the case studies in speciﬁc applications, as shall be discussed in chapter 8 and chapter 7.

A penultimate chapter 9 assesses the key results and reﬂects upon the lessons learnt. As stated earlier, we assess our results on the basis of the design science research criteria as proposed by (Hevner et al. 2004). Finally, we summarize the contributions made by this research, identify some future work and conclude in chapter 10.

1.14 Publications

The following is a list of scientiﬁc publications related to this thesis. I have been the ﬁrst author in all except those where it is otherwise mentioned. With each publication listed below, I also mention the chapters where the contents are referred to.

1. Vandana Kabilan, Paul Johannesson, Sini Ruohomaa, Pirjo Moen, Andrea Her- rmann, Rose-Mharie Ahlfeldt,˚ and Hans Weigand. Introducing the Common Non-Functional Ontology. Proceedings of 3rd International Conference on In- teroperability for Enterprise Software and Applications, INTEROP-ESA 2007. This work deals with analysis and representations of non functional aspects in enterprise systems like trust, privacy, security, misuse and threat, digital rights management, contracts, risks and quality of service. This paper proposes a common upper ontology for describing generic non functional aspects. Prof. Paul Johannesson and I have together been the main architect for this. Furthermore, the author has contributed with the sub ontology for business contract and risk. Due to space considerations, this work is not included in this thesis. 1.14 Publications 27

2. Vandana Kabilan,Pernilla Svan. ECA Rule Ontology: Modeling Prescriptive Rules as Descriptive Ontology. Proceedings of 3rd International Conference on Web Information Systems and Technologies, WEBIST2007, Barcelona, 2007. Parts of this paper has been included in section 6.5.6 and in section 8.7.2.

3. Vandana Kabilan,Hans Weigand. Risk Assessment of Business Contracts. 1st In- ternational Workshop on Interoperability Solutions to Trust, Security, Policies and QoS for Enhanced Enterprise Systems (IS-TSPQ ) 2006, collocated with INTEROP-ESA 2006. An overview of this work has been given in section 7.13.4. Details may be referred in the publication.

4. Vandana Kabilan, Antonio De Nicola, Michele Missikoff,Vahid Mojtahed. Practi- cal Issues in Ontology Modeling: The Case of the Defence Conceptual Modeling Framework-Ontology. INTEROP-ESA 2006. The requirements analyzed in this paper have been integrated in to the requirements for our proposed O4IS design methodology.

5. Jelena Zdravkovic, Vandana Kabilan. Enabling Business Process Interoperability Using Contract Workﬂow Models. Proceedings of 13th International Conference on Co-operative Information Systems (CooPIS) 2005. I am the second author for this paper and I contributed the sections relating to the multi-tier contract ontology, the contract workﬂow, and the case scenarios.

6. Vandana Kabilan, Contract Workﬂow Model Patterns Using BPMN. Proceedings of 10th International Workshop on Exploring Modeling Methods in System Anal- ysis and Design,collocated with CAiSE 2005. Parts of this work has been included in section 7.12.5.

7. Vandana Kabilan, Jelena Zdravkovic, Paul Johannesson. Using Multi-Tier Con- tract Ontology to Deduce Contract Workﬂow Models for Enterprise Process In- teroperability. Proceedings of 2nd INTEROP-EMOI Open Workshop on Enterprise Models and Ontologies for Interoperability, Co Located with CAiSE 2005. Parts of this work may be seen in section 7.12.3.

8. Vandana Kabilan, Paul Johannesson. UML for Ontology Modeling and Interoper- ability. Proceedings of 1st INTEROP-EMOI Open Workshop on Enterprise Models and Ontologies for Interoperability, Co Located with CAiSE 2004. This paper has been referenced in this thesis but not directly included. 28 1 Introduction

9. Vandana Kabilan, Using Multi-Tier Contract Ontology to model Contract Work- ﬂow Models. Licentiate Thesis. Royal Institute of Technology. Stockholm 2003. Parts of the licentiate thesis have been included in the case study I, chapter 7.

10. Vandana Kabilan, Paul Johannesson. Semantic Representation of Contract Knowl- edge using Multi-Tier Contract Ontology, Published in the proceedings of Seman- tic Web and Databases workshop, (SWDB 2003) Co Located with VLDB 2003. Parts included in section 7.8.

11. Vandana Kabilan, Paul Johannesson, Dickson Rugaimukammu. An ontological approach to Uniﬁed Contract Management. The proceedings of 13th European Japanese Conference on Information Modeling and Knowledge Bases, held on June 6-7th 2003,Kitakyushu, Japan. Published by IOS Press. The paper presents the idea summarized by the case study I.

12. Vandana Kabilan, Paul Johannesson, Dickson Rugaimukammu. Business Con- tract Obligation Monitoring through use of Multi-Tier Contract Ontology. Pro- ceedings of Workshop on Regulatory Ontologies (Worm CoRe 2003), November 2003, Italy. Springer-Verlag publications (Lecture Notes in Computer Science). Parts of this paper is included in section 7.9.2.

13. Moustafa Chenine, Vandana Kabilan, A Pattern for Distributed Heterogeneous Ontologies for facilitating Application Interoperability, 3rd Open INTEROP Work- shop On ”Enterprise Modeling and Ontologies for Interoperability” (EMOI 2006), co-located with CAiSE 2006. June, 2006. I am the second author. The paper is on an ontology to support interoperability between distributed systems. This paper is not included in this thesis.

Technical Reports and Other Publications

14. Birger Andersson, Vandana Kabilan, Marianela Garca Lozano, Vahid Mojtahed, Pernilla Svan, DCMF - Defence Conceptual Modeling Framework, Swedish De- fence Research Agency (FOI), November, 2005,FOI-R–1754–SE. I contributed chapter 4, 5, 7, and parts of 10.

15. Birger Andersson, Vandana Kabilan, Vahid Mojtahed, Pernilla Svan, Survey of Related Research and Approaches, Swedish Defence Research Agency (FOI), De- cember, 2005,FOI-R–1858–SE. I contributed chapter 9,10,11,13 and 14. 1.14 Publications 29

16. Birger Andersson, Vandana Kabilan, Marianela Garca Lozano, Vahid Mojtahed, Pernilla Svan, Konceptuell Modellering inom det Svenska Forsvaret¨ - DCMF, Swedish Defence Research Agency (FOI), 2006, ISSN 1650-1942. I contributed to chapter 3.

17. Vandana Kabilan, Vahid Mojtahed. Introducing DCMF-O:Ontology Suite for De- fence Conceptual Modeling. 06E-028-SIW. EURO SIW, European Simulation In- teroperability Workshop organized by SISO-STDS,2006. I am the ﬁrst author and parts of this work has been included in section 8.6.

18. Vandana Kabilan, Vahid Mojtahed. Adapting the JC3IEDM to DCMF-O: An Expe- rience Report. 06F-055-SIW. FALL SIW, FALL Simulation Interoperability Work- shop organized by SISO-STDS 2006. I am the ﬁrst author and parts of this work has been included in section 8.6.

19. Constantinos Giannoulis, Vandana Kabilan. A Method for VVA Tailoring: The REVVA Generic Process Tailoring Case Study. 07F-SIW-015. FALL SIW, FALL Sim- ulation Interoperability Workshop, 2007. I am the second author and the work is not included in this thesis.

O 2

Knowledge Management and Information Systems

In this chapter, we briefly summarize and review some aspects from Knowledge Management and Information Systems. And conclude with their overlapping and common research field – Ontologies. In chapter 1 we introduced our interest in the design of ontologies for Information Systems. As said earlier, there are at least three tracks of research that are of particular interest to us since they overlap each other specifically in the design and use of ontologies. The first research focus is from the field of Knowledge Management. AI and Knowledge Management have been using ontologies for a long time. The second domain is that of conceptual modeling in Information Systems. Conceptual models as knowledge representations are popular and widely used in Information Systems. The third domain is that of the relatively new field of research in design of ontologies for Information Systems. To give the reader a comprehensive background of these three research domains, we begin with the basics of what is data, information, and knowledge. How do they differ from each other? How are ontologies the common ground between information management systems and knowledge base systems? These are some questions that we aim to answer through our summarization of some relevant aspects of these three domains. We begin with knowledge management and use of ontologies in knowledge management. In the next chapter (chapter 3) we survey the related research from ontologies in Information Systems and finally in chapter 4, we summarize related theories from Conceptual Modeling.

2.1 The Data-Information-Knowledge-Wisdom Model

DIKW is a proposal of the structuring of Data, Information, Knowledge and Wisdom in an information hierarchy where each layer adds certain attributes over and above the previous one. Data is the most basic level; Information adds context; Knowledge adds how to use it; and Wisdom adds when to use it. Its idea was suggested by Milan Zeleny and Russell L. Ackoff (1989). 32 2 Knowledge Management and Information Systems

As per Russell Ackoff (1989), DIKW model is summarized as :

1. Data: Is all about symbols and their use to denote some primitive and basic units of information. Data has been deﬁned as: Representation of facts, concepts, or instructions in a formalized manner suitable for communication, interpretation, or processing by humans or by automatic means. Any representations such as characters or analog quantities to which meaning is or might be assigned. 2. Information: Is about data that are processed to be useful; provides answers to ‘who’, ‘what’, ‘where’, and ‘when’ questions. Information is a structured and aggregated groups of data. Galliers (1987) deﬁnes: “Information as that collection of data, which, when presented in a particular manner and at an appropriate time, improves the knowledge of the person receiving it in such a way that he/she is better able to undertake a particular activity or make a particular decision” 3. Knowledge: Is the application of data and information; answers “how” questions. Knowledge consists of specialized facts, theories, procedures, and relationships between them. It is also information that has been organized and analyzed to make it understandable and applicable to problem solving or decision making. 4. Understanding: Is the appreciation of ‘why’ any given facts occur. Realization of what is the implication of a collected information. 5. Wisdom: Is an evaluated understanding gained over a period of time or through experience. When understanding is utilized to gain or improve the current situation, we say that wisdom has been used.

Data refers to a statement without reference to any context,for example– ‘5’ is just a number or data. If we complete it and say ‘5 degrees centigrade’ then we have information, yet it is just a ﬁgure and does not convey any meaning unless we complete the statement like – ‘the outside temperature is 5 degrees’, when it becomes a knowledge of the climatic condition. A realization that it’s the winter season, and its cold outside is ‘understanding’ the knowledge gained. Finally when we decide to cloth ourselves in warm clothes before venturing outside, we are applying our wisdom. From T D Wilson (2002):

“Knowledge is deﬁned as what we know: knowledge involves the mental processes of comprehension, understanding and learning that go on in the mind and only in the mind, however much they involve interaction with the world outside the mind, and interaction with others. Whenever we wish to express what we know, we can only do so by uttering messages of one kind or another - oral, written, graphic, gestural or even through ‘body language’. Such messages do not carry ‘knowledge’, they constitute ‘information’, which 2.2 Information Systems 33

a knowing mind may assimilate, understand, comprehend and incorporate into its own knowledge structures.”

According to Wilson, everything outside the mind that can be manipulated is ‘data’, and they are simple facts. It becomes ‘information’ when the data is embedded in some relevant context. Folder like collections of these information is referred to as ‘information resources’. Wilson contends that while data and information can be managed, knowledge can never be managed. He has carried out a statistical survey of knowledge management topic related publications in conferences and journals, and purports that contemporary knowledge management concept is a fad and a new coined term for information management.

2.2 Information Systems

While there is a consensus on what is information, we find a myriad definitions of what constitutes an information system. Some of them are collected in table 2.1: As we can see in table 2.1, we have a wide range of definitions, but they all prescribe to the same fundamental principle, that an information system is a mechanism for humans to manage the organizational processes through the utilization of IT and processing of data. As stated in section 1.1 we uphold the definition of an information system as given by Gupta (2000) that Information Systems is both a field of study as well as an artifact that can be used for processing, storing and manipulating information for gaining knowledge by humans. We denote Informa- tion Systems with the capital letters for the field and in small letters as ’information systems’ when we refer to the artifact or physical system and components that constitute an Information System. As such, humans form the central pivotal key-pin without which information systems should cease to function. This differentiates information systems from artificial intelligence systems, which are aimed to operate and function automatically without human intervention. Today most information systems use some form of data source as the repository where data is archived. These are processed to provide the users with information. But, we have had the existence of knowledge base systems for the past two or three decades as well. Knowledge bases use knowledge resources. So, how do these two differ? 34 2 Knowledge Management and Information Systems

Table 2.1. Definitions of Information Systems Collected Definitions for Information Systems A set of people, procedures and resources that collects, transforms and disseminates information in an organization; a system that accepts data resources as input and processes them into information products as output; a system that uses the resources of hardware, software and people to perform input, processing, output, storage and control activities that transform data resources into information products; a purposefully designed system that brings data, computers, procedures, and people ...– Glossary of Terms, Management Information Systems (Web Resource) An information system is the arrangement of people, data, processes, presentation of data, and information technology that supports our everyday needs.– Key Terminology, Computer and Information Technology (Web Resource) Any equipment or interconnected system or subsystems of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, trans- mission, or reception of data and that includes computer software, firmware, and hardware. Included are computers, word processing systems, networks, or other electronic information handling systems and associated equipment. –Information Assurance Terminology,IASO certification course,School of Information Technology. (Web Resource) In Information Systems, an information system consists of three components: human, task, application system. In this view, information is defined in terms of the three levels of semiotics. Data which can be automatically processed by the application system corresponds to the syntax-level. In the context of an individual who interprets the data they become information, which correspond to the semantic-level. Information becomes knowledge when an individual knows (understands) and evaluates the information (e.g., for a specific task). This corresponds to the pragmatic-level. – Information Systems. (Web Re- source) An information system is a set of interacting artifacts and human activities that performs one or more functions involving the handling of data and information, including data collection, creation, editing, processing and storage; and information selection, filtering, aggregation, presentation and use.– Clarke (1995)

2.2.1 Knowledge Base Versus Database Information Systems

The differences between KBMS(Knowledge Base Management Systems) and DBMS (Data Base Management Systems) has been examined by John Mylapoulos (1985) in his essay “On Knowledge Base management Systems”. He distinguishes KBMS (whose purpose he describes is to ‘facilitate the management of large, shared knowledge bases’) from DBMS on three accounts as follows: 2.2 Information Systems 35

1. First, he states that DBMS make a clear distinction between ‘generic’ knowledge and ‘ground knowledge’. Mylapoulos explains that the abstract generic concepts are modeled in to the database schema whereas the day to day, observations or the speciﬁc information ‘data’ are put in to the schema by the end users. In a KBMS, Mylapoulos says that this distinction disappears. In our opinion, this distinction focuses more on the design approach and ‘physical’ level. On the knowledge level, we can say that the ‘generic’ database schema models the patterns of knowledge whereas the database holds the ‘instances’ of the same. In other words a knowledge base could said to be a highly specialized version of a database. 2. The second difference, according to Mylapoulos, is that DBMS are function- oriented; they focus on end user requirements. In this context he refers to KBMS as a ‘prototyping facility for a particular kind of software’ rather than a facility for management of large databases. He supports his argument by saying that a KBMS is not intended to provide user interfaces but it is possible to include in the KBMS framework facilities for lexicon, grammar and pragmatic knowledge as well. 3. The third difference he mentions is that once the KBMS is ‘epistemologically adequate’ it should be possible to generate code from it. By this we interpret that the ﬁnal KB designed should be machine-readable.

2.2.2 Knowledge Bases and Knowledge Base Systems

The above theories have undergone changes in the last two decades since the book was ﬁrst written. The Decision Support Systems Power (1995) glossary deﬁnes knowledge as:

“Knowledge refers to what one knows and understands. Knowledge is sometimes categorized as either unstructured, structured, explicit or tacit. What we know we know is explicit knowledge. Knowledge that is unstructured and understood, but not clearly expressed is implicit knowledge. If the knowledge is organized and easy to share then it is called structured knowledge. To convert implicit knowledge into explicit knowledge, it must be extracted and formatted.”

Ontologies are intended to make implicit domain knowledge explicit. In that respect, we see that ontology is a knowledge representation form. But are the two synonymous? An interesting compilation of different deﬁnitions for Meta-data, taxonomy, thesaurus, ontology, and knowledge base has been given by Victor Lombardi (2003) on the online article. He has deﬁned an knowledge base as: 36 2 Knowledge Management and Information Systems

“An ontology populated with data.”

In the EU CORDIS (Web Resource) database, glossary the term ‘Knowledge Base’ has been deﬁned as:

“A collection of stored facts, heuristics and models that can be used for problem solving.”

The schema and classiﬁcation of a knowledge base is described by an ontology. But an ontology with its populated instances together constitute a knowledge base. Thus it becomes apparent that ontology is a form of knowledge base. Ontologies play a role as a central knowledge base in a knowledge management system. We now explore the scope of knowledge management and the roles that ontologies play in knowledge management.

2.3 Knowledge Management

Having explored the concepts of knowledge and knowledge bases, we now turn towards knowledge management.

“Knowledge management is a management theory which emerged in the 1990s. It seeks to understand the way in which knowledge is used and traded within organizations and treats knowledge as self-referential and recursive. Knowledge Management is a strategy, framework or system designed to help organizations create, capture, analyze, apply, and reuse knowledge to achieve competitive advantage.”

– Milton (2003) Knowledge Management is gaining momentum due to increasing developments in the field of e-commerce. As mentioned earlier, organizations need to re use and harness their knowledge to increase their efficiency, performance and profitability. In such contexts the identified needs for Information Systems (as discussed in section 1.3) is similar to the goals of knowledge management. Malhotra (2001) extrapolates knowledge management as:

“crucial construct in understanding how humans convert information into thought and consequently into action.”

He goes on to say that expert systems and AI systems could beneﬁt from this understanding and is a relevant issue to human and machine- based knowledge systems. Malhotra has also collected a set of varying deﬁnitions for knowledge management, some of the more interesting ones are listed below: 2.3 Knowledge Management 37

• “The process of collecting,organizing, classifying and disseminating information throughout an organization, so as to make it purposeful for those who need it.”– Albert (1998) • “Knowledge Management in general tries to organize and make available important know-how, wherever, and whenever needed. This includes processes, procedures, patents, reference works, formulas, best practices, forecasts and ﬁxes.”– Maglitta (1996).

Malhotra (2001) goes on the define two paradigms - Information Processing and Sense Making for knowledge management. Information Processing, he contends, is the data oriented processing of a problem, according to predefined algorithm and preset solutions. He reiterates the need for Sense Making, that is defining how humans understand and process information in its different contextualities and meanings to moderate their actions and in turn their performances. Malhotra, we see thus, had begun to unravel the notion of semantics. On intro- spection, we can see that ontologies are nothing but knowledge resources and their domain descriptions range through all kinds of information and data. Going beyond the capability of traditional databases, ontologies have the capacity to further ‘make sense’ of the captured information. But, ontologies may even be placed on a higher level, if logic and reasoning were to be supported as well, as we shall see in section 3. Turban (1993) defines Knowledge Engineering as a process of building expert systems that are forms of Artificial Intelligence systems. He further defines the role of a Knowledge Engineer as –

“one who extracts knowledge from a human expert and then translates this knowledge into a database known as the Knowledge Base which contains all the collected knowledge related to the problem to be solved. He draws the parallel to software system analyst role in the software engineering discipline, where the specialist extracts the end users requirements and translates them into speciﬁcations and requirements for the designer, developer or pro- grammer to work from.”

There are five phases of Knowledge Engineering: Knowledge Acquisition, Knowl- edge Representation, Knowledge Validation, Inference, Explanation and Justifica- tion. The first relates to the mechanisms and approaches for collection of knowledge, the second relates to how the gathered information is analyzed and represented, the third relates to validation of the knowledge representation, thereafter the models are to be explained and justified. R But given the focus and theme of this research, that of domain knowledge representation as ontology for use in Information Systems, we limit our review and discussion to the Knowledge Representation phase only. 38 2 Knowledge Management and Information Systems

2.3.1 Knowledge Representation

The study of knowledge or the subject of epistemology was long established by Plato. Aristotle developed a systematic terminology for representing knowledge. In addition he also developed Logic as a precise method for reasoning about knowledge. He invented Syllogism as a three part pattern for representing Logical Deduction (Poste- rior Analytics). Having discussed earlier in this chapter, the DIKW model, knowledge and its need for management, we now focus on the key aspect vital to this research – Knowledge Representation. In this section, we shall review the roles that Knowledge Representation may have and focus on the ones that are relevant for this research.

2.3.2 Different Roles of Knowledge Representation

Davis, Shrobe and Szolovits (1993) describe five different roles of Knowledge Rep- resentation in the AI field,and with that five different purposes for representing the captured knowledge. We shall use these as criteria to evaluate our proposed USP2 Design in section 9.3. Briefly Davis et al’s proposed roles may be summarized as:

Role I: KR as a Surrogate.

The knowledge representation is a stand-in replacement model for the real world which it aims to describe. This is essential for an artiﬁcial intelligent agent to read, understand, and compute about. In this role, a KR would have to be as perfect as possible, as the inferences that can be made by the artiﬁcial agent is only as good as the KR model is to the real world. For example, if the KR model is imperfect in its descriptions of the entities and relationships that it endeavors to capture, then any logical inference based on these imperfect facts is likely to be imperfect as well.

Role II: KR as a set of Ontological Commitment.

In this role, Davis et al argue that, once you make choices for a set of potential uses, then we choose to describe the parts of the world we wish to see or use, given that we make imperfect approximations in the KR. That is, they propose that choosing a KR is a set of ontological commitment, because by making conscious decisions about the boundaries and aspects of the world that is relevant for that KR, we are limiting the imperfections that can arise. Ontology is a suitable form of KR in this role. Though there are many ontology representation languages like KIF (Knowledge Interchange Format), F-Logic(Frame Logic) and OCML (Ontology Conceptual Modeling Language), Davis et al hold that – “the essential information is not in the form of that language but the content, i.e, the set of concepts offered as a way of thinking about the world.” We shall return to this role of KR and Ontology again, when we discuss the role of ontology in Information Systems. 2.3 Knowledge Management 39

Role III: KR as a fragmentary theory of Intelligent Reasoning.

The authors believe that this role comes about because the KR is based on an initial conception or view of the world, based on some insight or belief on how people reason intelligently. As they say: “The theory is fragmentary in two distinct senses: (i) the representation typically incorporates only part of the insight or belief that motivated it, and (ii) that insight or belief is in turn only a part of the complex and multi-faceted phenomenon of intelligent reasoning.” For AI and applications in AI, this is a key role for any KR, and Ontologies de- ﬁned within the scope of AI adhere to this role. Hence the choice for KR is usually formal logic based languages 1 instead of frame based languages 2 as is common in Information Systems. (Gruninger and Uschold have proposed a classiﬁcation of ontologies based on their types, as shall be discussed in section 3.4, the basis for which may be seen in this section on KR and its roles)

Role IV: KR as a medium for Efﬁcient Computation.

The authors contend that for any machine to use a KR, it should be able to compute it. In this context, the authors make an interesting yet vital observation- Frames were introduced to be able to describe stereotyped situations in real world. Con- straints and rules associated with it could also be represented. A highly computable KR was achieved but with limited expressive power as proposed by KR languages by Doyle & Patil (1989). This contrasted with the earlier philosophy of epistemological (knowledge content) value being greater than computability as put forward by Hayes (1985). This discussion shall become relevant, when we discuss the choice of ontology representation language in section 5.4, where one has to decide between the trade off between expressivity versus computability.

Role V: KR as a medium of Human Expression.

The fifth and final role as put forward by Davis, Shrobe & Szolovits (1993) is that of human communication as they aptly summarize: 1 First-order logic (FOL) is a language in symbolic science, which is used by mathematicians, philosophers, linguists, and computer scientists. FOL has sufficient expressive power and can express almost all mathematical formalizations. It can capture rules, axioms, transformation rules etc. However, they are seldom readable or comprehensible to the common humans, unless they are well versed in the FOL 2 The concept of Frames was first introduced by Marvin Minsky. in the 1970s. A ‘frame’ is a data structure, used for knowledge representation, much similar to the fragmentary theory role of KR as proposed by Davis et al. The Frame is like a concept, class or object which de- limits the boundaries in whose context the real world is to be described or conceptualized. Each frame has properties, attributes or slots which describe characteristics and features of the object of interest. Current W3C standard for ontology, OWL is one such frame based language. Other examples are OIL, F-Logic. 40 2 Knowledge Management and Information Systems

“knowledge representations are also the means by which we express things about the world, the medium of expression and communication in which we tell the machine (and perhaps one another) about the world. This role for representations is inevitable so long as we need to tell the machine (or other people) about the world, and so long as we do so by creating and communicating representations. ”

As stated earlier, Information Systems aim to enable effective communication between humans and organizations. Thus the linkage between IS and Knowledge representations like ontology becomes evident. We shall revisit this subject when we review the proposed uses of ontology in IS in section 3.2. R In this research, we have focused mainly on the use of Ontology as a KR for human expression, Ontological commitment and partly as a surrogate model for the real world in IS. We use the above mentioned roles as principles for Knowledge Representation and these form the evaluation criteria for our USP2 Design and the Semantic Analysis Representation in section 9.3.

2.4 Relevance of Chapter

To recapitulate, we have explored the concepts of Information Systems and knowledge base systems. We have seen that the distinction between the two is fast disap- pearing. We have established that knowledge representations as the common factor between the two. We have argued for the ontological conceptualization of a domain to be a re-usable knowledge representations. Having established these basics, we now move on to the related theory and research from the world of ontology. O 3

Ontology and Information Systems

Ontology has its origin in philosophy and can be traced way back to Aristotle who defined it as a description of the world as exists. Since then, we can trace its evolution in the works of Husserl, Kant, Frege and Carnap amongst others. Ontology then became associated with logic. Philosophers describe the real world as consisting of Ontology, Logic and Computational Models. Ontology provides the concepts, their relationships; Logic gives the axiomatic description of their complex behavior, and constraints whereas the computational models would impart the system dependent perspective. In this chapter, we shall begin by reviewing the myriad definitions of ontology, from philosophy, meandering through AI and finally ending up in Infor- mation Systems. Then, we move forward to review some proposed categorization of ontology within Information Systems. We summarize some accepted design criteria for ontology as put forward by Gruber. Moving on, we describe some ontology architectures. Finally, we review some selected state of the art ontology design methodologies.

3.1 Ontology

Different researchers have given different definitions. A succinct review of the history and background of ontology has been carried out by Chira (2003). Chira has clarified that researchers while developing ontologies employ ontology-based meanings to depict their own understanding of the concept in their particular field and for their particular needs. That is he upholds the AI perspective of an ontology that ontology is a specification of a conceptualization. Some of them are listed below to give us an overview of the depth and variety of definitions of ontology in philosophy, AI, KM and Information Systems. The term ‘ontology’ has been defined in philosophy as:

“A branch of metaphysics concerned with identifying, in the most general terms, the kinds of things that actually exist. Thus, the ontological commit- 42 3 Ontology and Information Systems

ments of a philosophical position include both its explicit assertions and its implicit presuppositions about the existence of entities, substances or beings of particular kinds.” Barry Smith (2004) defines ontology in information system as: “An ontology is a software (or formal language) artifact designed with specific set of uses and computational environments in mind. An ontology is often something that is ordered by specific client in a specific context and in relation to specific practical needs and resources.” Smith traces the first use of the term ‘ontology’ in computer and information science to as early as 1967, in the work of S H Mealy (1967), who distinguished between different forms of data modeling. Mealy proposed that the data models were representations of the real world and its ideas of how it existed in the minds of men, and how they were represented as ‘symbols on paper or some other storage medium’. Another interesting observation made by Barry Smith (2004) is that Proceduralists believed the way to create intelligent systems was by instilling in to a system as much knowledge how as possible, whereas, Declarativists believed that the approach was to instill as much knowledge what as possible - in the form of knowledge representations. In the realm of database modeling, procedural knowledge is being captured via software programs and code (operational logistics, triggers and so on) while the data structures are representations of the objects and concepts. But to reuse and generalize the knowledge, one needs to build declarative representations of procedural knowledge as well. Other researchers like Gruber gave one of the popular definition of an ontology as: “An ontology is an explicit specification of a conceptualization.” -Gruber (1993a). Though a vocabulary is nevertheless needed to describe the universe of discourse,the advantage of Gruber’s definition is that it makes the need for ontology to be explicit – publicly available and not embedded as part of any knowledge base systems. Also, Gruber’s definition gained further acceptance with the advent of the Semantic Web, the definition of ontology as a conceptualization of a domain. Borst, H. & Top (1997) have elaborated Gruber’s definition as: “Ontologies are defined as formal specification of a shared conceptualization.” Studer, Benjamins & Fensel (1998) has combined both Gruber and Borst’s definition as: “Ontologies are explicit formal specification of a shared conceptualization.” 3.1 Ontology 43

Studer (1998) has explained the term as follows:

• Explicit: The type of concepts used and the constraints on their use are explicitly defined. • Formal: The ontology should be machine readable which includes natural language. • Shared: Reflects the notion that an ontology captures consensual knowledge, that is, it is not private to some individual but accepted by a group. • Conceptualization: “abstract model of some phenomenon in the world by having identified the relevant concepts of that phenomenon.”

In contrast, we have a pragmatic approach from Noy & McGuinness (2001), who have based their definition on their practical experiences of developing both formal AI ontologies using different representation formalisms and tools as well. “An ontology is a formal explicit description of concepts in a domain of discourse - classes (sometimes called concepts); properties of each concept describing features and attributes of the concept - slots(sometimes called as roles and properties as well); and restrictions on slots - facets (sometimes also called as role restrictions).” Mike Uschold (1998) holds the view that: “An ontology may take a variety of forms, but necessarily it will include a vocabulary of terms, and some specification of their meaning. This includes definitions and an indication of how concepts are inter-related which collectively impose a structure on the domain and constrain the possible interpretations of terms. An ontology is virtually always the manifestation of a shared understanding of a domain that is agreed between a number of agents. Such agreement facilitates accurate and effective communication of meaning, which in turn leads to other benefits such as inter-operability, reuse and sharing.” Getting back to Guarino we see that he defines an ontology as:

“An ontology is an explicit, partial account of a conceptualization.” -Guarino & Giaretta (1995). Guarino (1998) further explains his deﬁnition as: “An ontology is a logical theory that constraints the intended models of a logical language.” He subscribes to the formal machine readable intensional description of the domain of discourse models as ontology. His suggested terminological differentia- tion between the philosophical branch Ontology with a capital ‘O’ and ‘ontology’ as knowledge engineering and AI perspective with a small ‘o’, is now widely accepted. 44 3 Ontology and Information Systems

As we see from this discussion, there is no clear consensus on the deﬁnition of an ontology in the context of Information Systems. It can range from being a formal logical theory to abstract conceptual models. For this research we uphold the deﬁnition of ontology to be as:

R An ontology is an explicit formal conceptualization of a shared understanding of the domain of interest including the vocabulary of terms, semantics as well as their pragmatics.

3.2 Uses of Ontologies

Noy and McGuinness (2001) have proposed the following possible uses for an ontology (ontology in their perspective is from a reusable knowledge base perspective, which consists of concepts, their attributes and their relationships):

• To share common understanding of the structure of information among people or software agents. • To enable reuse of domain knowledge. • To make domain assumptions explicit. • To separate domain knowledge from the operational knowledge. • To analyze domain knowledge.

All the above uses support inferencing capabilities. The first one could be targeted towards human understanding in which case we could use conceptual graphs, topic maps or UML class diagrams as representation medium. The second one pre- supposes the use of a common language for representation. For example reuse of other ontologies defined in different formats like KIF, LOOM, or OWL needs to be mapped or translated. The third application of ontology, to make implicit or tacit knowledge available, has a vital application for many domains like in the medical, legal and military domains. The fourth and fifth use as proposed by Noy & McGuin- ness (2001) is oriented towards the architectural design and end application uses. In addition to the above, ontology is being used as a central knowledge pool for a variety of Information Systems applications and services like for web services, document management systems, enterprise management systems, contract management systems amongst others. Thus in the specific context of interoperability of Informa- tion Systems, we may summarize the potential use of ontologies as:

Ontology can be used as a central component of interoperability of Informa- tion Systems application at data, information, knowledge and meta level.

Ontology supports interoperability at different levels like: 3.3 Ontology – A Historical Background 45

• Interoperability at Data Level: Ontology by themselves achieve interoperability at the lowest data level syntactic integration /schema integration by means of mapping of ontology or translation to existing knowledge base or data base formats. • Interoperability at Information Level: Information level of interoperability requires a set of methodologies in addition to the central ontology. Query and search facilities like that of Xpath, Xquery, SparQL and RACER enable interoperability between like-minded ontologies. • Interoperability at Knowledge Level: Interoperability at knowledge level requires the ontology to be visualized at the conceptual model level, or meta data model level as is popularly known in Information Systems. This segregation of speciﬁcity is similar to most modeling architectures like the MDA 1; DoDAF 2; NAF 3 ; and the Zachman Framework (1987).

This research is focused on the knowledge level conceptualization, and thus our interest lies in the possible use of ontologies for information to facilitate ‘knowledge level interoperability ’ or ‘semantic interoperability’ as it is better known.

3.3 Ontology – A Historical Background

To understand the ontological foundations for Information Systems we need first to survey the different approaches and beliefs that have been prevalent in different scientific disciplines. We now briefly summarize some of the salient thoughts and relevant literature from philosophy, AI, logic, linguistics and knowledge management. Thereafter, we shall take a closer look at ontology design in Information Systems.

3.3.1 From Philosophy, AI and Logic

In this section we review some of the relevant literature from the philosophical ontology. We highlight the thoughts and views of logicians and philosophers that have influenced this research. Origin of ontology is in philosophy and is intended to be the study of the world as it exists. But there are different views regarding the definition of the world and the quest of absolute versus relative truths. One such view is that of defining ‘possible worlds’ which may be a subset of the ‘real world’. The concept of ‘possible worlds’ was first introduced by Saul Kripke (1959) and his colleagues in the 1950s. 1 Model Driven Architecture 2 The DoD Architecture Framework, Department of Defence, USA, DoD Architecture Frame- work Version 1.0, volume 1. Definitions and Guidelines. 9 February 2004. Available online at http://www.defenselink.mil/nii/doc/DoDAF_v1_Volume_I.pdf Last accessed on 2006-02-01 3 The NATO C3 Architecture Framework. NATO C3 Technical Architecture web page 46 3 Ontology and Information Systems

Susan Haack (1978) has summarized that there are different approaches to the believers of ‘possible worlds’ as: I. The linguistic approach – as proposed by Hintikka (1962), in which possible worlds can be interpreted as set of ‘consistent sentences’ either syntactically or semantically. II. The conceptualist approach – like that proposed by Kripke (1976) where the possible worlds talk about different ways in which we perceive the world. III.The realist approach – which talks about the world as it is, wholly independent of language and thought as proposed by DK Lewis (1973). This research holds the view that the knowledge management discipline aims to follow the conceptualist approach. IS designers could be classified as belonging to the realist approach. For example they would prefer ‘language independent’ in their context to imply ‘platform independent’ approaches such as the semantic web development. But a closer look, reveals that ontology as we understand today, spans across all the approaches discussed so far. It is a theory that describes concepts and relationships that can be used to describe the world of existence. It is an artifact when the same is given a concrete formal representation along with the logic (that is the grammar) subscribing to formal logic sentences. It is a model for knowledge sharing, communication and interoperability when quantified within set parameters and boundaries for specific targeted domain applications. For example the model could be a graphical UML class diagram describing the semantics independent of any language. But we can see that an underlying commonality to all these perspectives is that they all intend to describe a world by using a set of concepts and relations which are like the alphabets and grammar for constructing both prose, poetry and a new language itself. The above view has been supported by Jacquette Dale (2002) in her writings. Dale distinguished between pure philosophical ontology and applied scientific ontology, which may be deemed to be similar to the discussed concepts of Ontology (with the capital O) and ontology (in AI and Information Systems). She says, to quote,

“..pure philosophical and applied ontology, complement one another. No metaphysics of being can claim to be complete if it does not keep each separate and in its proper place while providing the satisfactory answers to both specialized sets of problems. It is as much a mistake to investigate only the more tractable problems of applied scientific ontologyas it would be to de- vote attention exclusively to the fundamental problems of pure philosophical ontology to the neglect of making substantive commitments to the existence of real entities in applied scientific ontology. We should not try to establish a domain of existent entities that is not guided by a prior clarification of the concept of being; but having addressed the problems of pure philosophical 3.3 Ontology – A Historical Background 47

ontology, we must then move on to ﬁll in the details of a preferred existence domain as a contribution to applied scientiﬁc ontology.”

R The above quotation nearly sums up the philosophy of this research. But a deeper discussion of the quoted text is warranted. If we approach it from the philosophical or metaphysics perspective, we see that it proposes the existence of problems in the philosophical understanding of beings that exist in that it tends to become too abstract or detached from reality to be of any practical use to the proposed users of this philosophical knowledge. On the other hand, it also points out the fallacy of trying to create models of domain knowledge without a strong linkage and roots in the philosophical approach. Roberto Poli (2003) distinguishes further between Husserlian formal ontology, descriptive and formalized ontologies. He discusses the role of Logic in these formalisms of ontology. While some philosophers have subscribed to the distinction between ontology, logic and computation models, Husserl’s Logical Investiga- tions (1970), incorporates logic to be an essential part of formal ontology. This theory has been followed by Brachman and followers of AI where Formal ontology, includes concepts, mereology and logical axioms and theorems. However, today, in Tim Berner Lee’s vision for the Semantic Web(2001), we see Logic as a super im- posed layer on top of the ontology layer in his semantic web tower. From a more knowledge representation perspective or to say ‘technological’ aspect, this has been now interpreted as using a robust concept base using the W3C recommended Web Ontology Language (OWL) which, interestingly uses Description Logic to model axiomatic relationships between the concepts. It is still unclear as how the distinction between primitive logical restrictions on concepts and the expression of domain ‘rules’ as separate Logic layer is to be achieved. This could also be from traditional software engineering methods and design principles.

3.3.2 From Linguistics to Information Systems

From Nirenburg and Raskin (2001), we see that: “Ontological Semantics is a theory of meaning in Natural Language and an approach to NL (Natural Language Processing) which uses an ontology as a central resource for extracting and representing meaning of natural language texts, reasoning about knowledge derived from the texts as well as generating natural language texts based on representations of their meaning”. They emphasize the need for philosophical support to ontology conceptualizations and put forward a list of uses for ontologies other than simply knowledge resources as:

• To supply the language to explain the lexical meanings. 48 3 Ontology and Information Systems

• To provide the contentful building blocks of a text meaning representation. • To provide heuristic knowledge for dynamic knowledge resources like semantic analyzers and generators.

We agree with Nirenburg and Raskin (2001) that it is a crucial decision for the ontology designer to choose which concepts to introduce and how to represent them. They also recommend that a good ontology will have coverage and be reasonably homogeneous. Coverage of ontology is determined by the nature of the application which is similar to the purpose deﬁnition of ontology as recommended by researchers like Gruninger (1995), or Noy and Hafner (Fall 1997). Nirenburg and Raskin propose that formal ontology can help to decide how to organize the concepts that must be included. In “Ontological semantics” (Nirenburg & Raskin 2004), they propose that for an intelligent agent, the following components are relevant:

• Knowledge about the world, which is again subdivided into: – An ontology which contains knowledge about types of things (objects, processes, properties and intentions). – A fact repository, an episodic memory module containing knowledge about instances of the above types and their combinations. • Knowledge of natural language, including for each language: – Ecological, phonological, morphological, syntactic and prosodic constraints. – Semantic interpretation and semantic realization rules and constraints formulated as mappings between lexical units of the language and elements of the world model. – Pragmatics and discourse related rules that map between modes of speech and inter-agent situations, on one hand and syntactic and lexical elements of meaning representation language on the other hand. • Emotional states that inﬂuence the ‘slant’ of discourse generated by an agent. • An agenda of intentional plan for an agent.

Nirenburg and Raskin’s view on computational linguistic application capable of supporting reasoning is as follows:

“such comprehensive systems must have knowledge about speech situations, goal-oriented communicative actions, rules of semantic and pragmatic inference over symbolic representations of discourse meanings and knowledge of syntactic, morphological and phonological/graphological properties of particular languages.”

3.3.3 From Knowledge Management to Information Systems

Another relevant theory that has profoundly inﬂuenced this research is that of John Sowa. John Sowa’s (Sowa 2000) discourse on concepts in the lexicon, discusses the 3.3 Ontology – A Historical Background 49 problems and issue in lexical analysis, representation of the lexicon and its relations to the syntactic, semantics and the world knowledge and also presents some uses of lexicon in parsing, semantic interpretation, discourse analysis etc. Sowa deﬁnes ‘The lexicon is the bridge between a language and the knowledge represented by that language’. Sowa further summarizes previous related research on knowledge representation as:

• Semantics, not syntactics is the key to understand language. Traditional gram- matical categories are manifestations of fundamental semantic categories. • Every word is associated with a characteristic underlying semantic pattern, that determines how it combines with other words in a sentence. • The grammar of a language is then reduced to simplistic rules that determine what words can occur to the left or right of a given word. The variety of sentence patterns, is then a result of the complex interactions between simple grammar and the underlying semantic structures. • The meaning of the sentence is then obtained by the combination of semantic structures of the constituting words. • Denotation of a sentence in a possible world is computed by evaluating its meaning representation in terms of a model of that world.

The above is the principle design rationale behind our proposed USP2 Design approach (chapter 6). For Lexical Representations Sowa (2000) proposes the use of canonical graphs, that are graphical and easy to understand. Yet another natural language analysis and representation in knowledge bases has been put forward by Dignum and van de Riet (1987). The authors contend that natural language is ambiguous but yet the best candidate to represent different kinds of knowledge uniformly. As Dignum and van de Riet say, this problem can be mitigated by a semantic representation of natural language as given by a linguistic theory. They use Functional Grammar (Dik 1978) for their proposed Conceptual Prototyping Language (CPL) for representing knowledge bases. In CPL, ﬁve kinds of logic are used, namely:

• First Order Logic in the form of Predicate Logic and four modal logic. • Alethic model logics (expressing logical necessity, physical possibility and meta- physical possibility) for representing constraints. • Deontic Logic used to deﬁne morality, norms and obligation like constraints that ought to be true. • Dynamic Logic is an extension of modal logic originally intended for reasoning of behavior and actions in linguistics, AI, philosophy and computer systems. • Temporal Logic for representing temporal aspects of knowledge representation. 50 3 Ontology and Information Systems

We shall see later in this thesis when we analyze different types of semantic relationships that we use the theory from deontic, dynamic and temporal logic. We use their theory to propose declarative conceptual models that can be used as analysis constructs in building ontologies for Information Systems.

3.3.4 What Information Systems can learn from Philosophical Ontology

Finally we believe that there is an inherent and basic similarity in ontology from the philosophical and applied scientific approach (Information Systems design science approach). If the philosophical ontology describes the world as it exists, then the scientific applied ontology describes the world as it should be. This brings us to another interesting issue of rationality, contextuality and relativity. Philosophical ontology intends to describe the world abstractly as it exists. This is in line with their quest for absolute truth and objectivity. The same has been indirectly pursued in Information Systems through ontological commitment as has been discussed by several ontologists in the realm of AI as well as Information Systems. Conceptualization of a domain is indeed intended to be free from subjective bias. Hence we see the proposal of generic ontology, domain ontology, task ontology, and we now also see the emergence of Meta-Ontologies. Gruber (1993a) speaks of coding biases and domain expert biases. However, the best efforts of the domain experts can attain only partial objectivity. Simply because the social domains we live in, are transient. Everything that exists in reality is subject to change in some way or the other. Descriptions of this world would thus be always in relative context of some other concept. Different theories of truth have been proposed like the coherence theory supported by Bradley (1914) and Rescher (1973) where truth is taken to be a set of coherence relations within the set of beliefs. On the other hand the correspondence theory supporters like Russell (1956), Wittgenstein (1961) take the value of truth not in relations to each other but its relation to the world, and its correspondence to facts (evidence). Tarski (1956) proposed a semantic theory, where truth is defined in semantic terms of its satisfaction. Susan Haack (1978) in her philosophy of logic summarizes Tarski’s (1944) semantic theory as having two categories:

• Adequacy conditions, conditions that any acceptable definition of truth ought to fulfill. • A definition of truth, using a formal language.

While the philosophers of classical logic have long debated on specifying the definitions of truth, its paradoxes and its criteria, we have seen the birth of other logic disciplines like Modal Logic, which try to resolve some of the issues of classical logic. Modal Logic aims to extend the classical logic by introducing natural language like quantifiers, for ex: ‘necessarily’, ‘possibly’, ‘strictly implies’. Today we have sev- 3.3 Ontology – A Historical Background 51 eral other offshoots of Modal logic as Subjective logic, Descriptive logic and Deontic logic to name a few. R In the current interest of the research topic of this thesis, we shall focus more on Descriptive and Deontic Logic. Descriptive Logic, because, web ontology language uses DL for its formal axiomatizations. Deontic Logic because we shall deal with business contract conceptualizations in the first case study, focusing on the obligations, commitments and their fulfillments through performance etc. For example, Yao-Hua Tan (1998) has used deontic logic in his analysis of directed obligations for electronic contracting. Others like Milosevic (2002) have used subjective logic. Asspassia Daskolupulu (2001) has used description logic for her analysis of contract performance monitoring. We shall review more about this related research in chapter 7. As discussed in this section, the concept of truth itself has been the subject of many interesting thoughts for the philosophers. Information Systems believes in pragmatic truth. Hence, it becomes more critical to establish the criteria for this truth. This pragmatic truth is normally realized as business ‘rules’ in an information systems application. For example, like ‘triggers’ and validations in databases. But to summarize, we see that evidence, explanation or the rationale behind a phenomena or the domain of discourse to be captured cannot be dissociated from the surroundings (context). Context of the concepts could be other influencing concepts (physical or abstract) including time, as well as the person making the observation (subjective bias). This is not to say, that there is no knowledge or truth value in such a domain ontology. The observations made realistically(contextually) by the Information Systems domain ontology engineers, can be rationalized and further abstracted (filtered) to extract the epistemic value of the knowledge. This would theoretically either prove or disprove the philosophical model of the same domain. The above discussion intended to support our belief that ontology and its theory as proposed by the philosophers is indeed put into experimental setups (domain of discourse under given parameters) to get falsifiable observations (by virtue of the results of the targeted uses) by the ontology engineers. The observations and experiences of the ontology engineers refine the initial setup till no further clarifications can be achieved. Hypothetically, this implies that the set of ontology concepts deduced inductively by the ontology engineer should be the same-as or equivalent-to the set of concepts as predicted by the philosophers. R To sum up, this thesis holds the view that ontology should aim to capture the essence of the domain being modeled as observed along with an explicit representation of its implicit knowledge, beliefs and assumptions. Within the scope of Information Systems, this thesis shall propose a methodology and architecture for design, development of ontology for use in Information Systems 52 3 Ontology and Information Systems domain applications. We shall illustrate the utility of the proposed methodology by applying on two different domains (business contract and business process, military simulations modeling) having different functionalities and requirements. Thus the generic methodology shall illustrate the differences needed in approach, conceptualizations and formalizations. But, we shall also show the wisdom of reusing expertise and knowledge gained from the formal version of philosophical ontology. So far we have discussed in the implicit and explicit differences in perception and definition of what is an ontology from philosophy, logic, AI and Information Systems. We now move on to reviewing different types of ontologies, design criteria and methodologies for ontology design in Information Systems.

3.4 Ontology Types

Uschold and Gruninger (1996) have discussed in detail the principles, methods and characteristics of ontologies. They have classiﬁed ontologies depending upon their formality and complexity as a continuum as belonging to the following major categories:

1. Highly Informal: Ontologies that are expressed loosely in natural language. 2. Semi- Informal: Ontologies expressed in a restricted and structure form of natural language. 3. Semi- Formal: Ontologies expressed in artificially formally defined language, like the ontolingua version of Enterprise ontology (Uschold, King, Moralee & Zorgios 1995). 4. Rigidly Formal: Those that are clearly defined terms with semantics, theorems and proofs like the TOVE Enterprise Ontology (Fox 1992).

Guarino (1997) proposes a classiﬁcation of ontologies under three headings, as follows:

1. By the level of detail. - Reference (off-line) ontologies. - Shareable (on-line) ontologies. 2. By the level of dependence of a particular task or point of view. - Top-level ontologies. - Domain ontologies. - Task ontologies. - Application ontologies. 3. Representation ontologies. 3.5 Ontology Architectures 53

Of the above major classification groups, the second based on level of dependence on the domain task or perspective is of interest to the current research. Guar- ino’s (1997, 1998) proposal is rather an architecture for domain ontology modeling, where the different perspectives are separated. Since this proposal has vastly influenced our own methodology, we now look at Guarino’s classification in detail.

3.5 Ontology Architectures

Methodology for defining ontology includes identifying the scope and use for the ontology. Then the domain knowledge is to be classified and concepts identified. Ontology is defined as a set of classes arranged in a hierarchy or taxonomy, where real world concepts are modeled as classes, their characteristics as attributes and inter-object relationships as relationships, properties or axioms. Guarino (1997, 1998) has defined ontologies as logical theory accounting for the intended meaning of a formal vocabulary, i.e. its ontological commitment to a particular conceptualization of the world. He has further classified ontologies, depending upon their generality as (figure 3.1):

Top level ontologies: Describe general concepts like time, space, matter, and event that are independent of domain or a particular problem. Domain Ontologies and Task Ontologies: Describe ontologies pertaining to a spe- ciﬁc domain or task. Application Ontologies: Describe concepts that depend upon both a domain and a particular task, usually being specializations of both ontologies.

Fig. 3.1. Ontology Architecture proposed by Guarino

Guarino proposes a bottom-up approach in designing. He suggests to identify the most specialized concepts needed in the application ontology, then the domain 54 3 Ontology and Information Systems ontology and task ontology. Finally, Guarino recommends to abstract into the top level ontology the generic concepts. In essence, his suggested approach is valid in those cases when the ontology is to be designed from scratch. This does not take in to consideration other previously existing ontologies or knowledge bases.

3.6 Ontology Design Principles

Gruber (1993a, 1993b) has formulated some criteria for design of formal ontologies mostly for artiﬁcial intelligence purposes that have now been widely accepted. We brieﬂy quote his proposed criteria below, which are self explanatory in their simplicity:

• Clarity: Ontology should be able to effectively communicate its intended meaning to its users. • Coherence: Ontology should support inferences that are consistent with its definitions. • Extendibility: Ontology should be designed to anticipate the uses of shared vocabulary. One should be able to define new terms based on the existing definitions. • Minimal encoding bias: According to Gruber, the conceptualization should be specified at the knowledge level without depending upon any symbol or language encoding. • Minimal ontological commitment: Finally, Gruber recommends that ontology should not restrict the domain being modeled, allowing the users the freedom to specialize and instantiate the ontology as required.

The above criteria have now become the biblical commandments for any ontology designer for AI and Information Systems as well. We see that these criteria deﬁne the requirements only on the ontology artifact that is to be designed and developed. It aims to only ensure that the ontology is correct, cohesive and true. R These criteria do not reﬂect upon the intended purpose for the designed ontology. The domain view that a designer adopts maybe different depending on the intended use of the ontology. We will return to this issue when we present our O4IS design methodology in chapter 5. We now move on to our review of some selected ontology design methodologies available today.

3.7 Ontology Development Approaches

In computer science and software design, top-down and bottom-up are well known strategies for planning the design and execution of any software development. The 3.7 Ontology Development Approaches 55 top-down approach emphasizes the planning and complete understanding of the system prior to the actual developmental work. The top-down approach was initially promoted during the 1970s by IBM researcher Harlan Mills and Nikklaus Wirth. In a bottom-up approach the individual elements of a system are designed and developed ﬁrst before they are put together to compose a whole system. This view became popular in the 1980s when the object oriented programming emerged. To- day, most software projects prefer a middle-out approach, that is begin by reusing pre-existing knowledge or code.

Fig. 3.2. Illustration for Top Down Development Approach

Figure 3.2 illustrates an example where we can use a top down approach effectively, like in the case of linealogy of the animal kingdom. In the above example, we can see an illustrative case where we start with the Family ‘Felidae’ (the cat family) and identify its ‘sub family’, thereafter the different ‘genus’ and so on till we get to the species of domestic cat, ocelot, lion and tiger. On contrast, if we were to build a family tree of ancestors, then we would begin at the ‘bottom’ that is ourselves and trace back to see – who are our parents, our grandparents, great grandparents, great-great grandparents and so on. This is an example for a bottom up approach. In the middle out approach, we would start by identifying ourselves and then building backwards to include our forefathers. At the same time, building the family tree forwards, by including our children, grandchildren so forth. 56 3 Ontology and Information Systems

In the context of ontology design, Uschold & Gruninger (1996) put forward the following motivation for using middle-out approach, as also illustrated in ﬁgure 3.3. A bottom up approach results in a high level of detail being captured, which requires a high degree of effort being invested and at the same time making it difﬁcult to spot ‘commonalities’ between the terms. This increases the risk of inconsistencies and leads to re-work.

Fig. 3.3. Motivation for using Middle-Out Approach

A top down approach, on the other hand, as Uschold & Gruninger (1996) argue, results in better control of level of detail. However, beginning at the top implies that some arbitrary high level concepts are pre-determined, leading to less stability in the ontology. Therefore, according to (Uschold & Gruninger 1996) a middle out approach “strikes the right balance”. By identifying the most important concepts ﬁrst and building outwards results in higher stability, lesser re-work and less overall effort. We agree with the above view and hence adopt and recommend the same strategy in our O4IS design methodology, as shall be introduced in chapter 5.

3.8 Ontology Design Methodologies

As stated earlier, in this section we survey some of the prominent ontology design and development methodologies, namely:

1. Uschold and Gruninger’s Skeletal Method. 2. Gruninger and Fox Method. 3. Noy and McGuinness ’s 101 Ontology Design Methodology. 4. UPON. 5. Methontology 3.8 Ontology Design Methodologies 57

Our choice for these specific methodologies has been based on the fact that the first two stated above are the amongst the first Information Systems oriented ontology design methodologies, and have been successfully tested in developing enterprise ontologies. The third is a popular guide to developing ontologies in one of today’s most widely used open source ontology editor. The fourth methodology surveyed is based on the RUP methodology and gives a detailed account of the activities to be carried out similar to a software development project plan. The final methodology is based on the first two and is also based on software development principles.

3.8.1 Uschold and Gruninger’s Skeletal Method

Uschold & Gruninger (1996) provides guidelines for ontology designing based on their experiences in designing the Enterprise Ontology (Uschold et al. 1995) which may be summarized as follows:

• Phase 1- Identify Purpose: Why the ontology is being built and what its intended use is, and who the targeted users are. • Phase 2- Building the ontology: In this phase the actual design of the ontology is suggested following the given steps below: - Ontology capture: Uschold and Gruninger suggest to (i) identify the key concepts and relationships in the domain of interest; (ii) produce precise and unambiguous textual descriptions of identified concepts; (iii) identify terminology to name identified concepts and relationships and finally (iv) to have a consensus on the concepts, relationships and their names. - Coding: This phase includes explicitly representing the knowledge /conceptualization captured in the previous phase using some chosen formal language. For this Uschold & Gruninger (1996) propose that the designer should commit to the basic terms identified in the previous term, choose a formal representation language and thereafter code the ontology. - Integrating existing ontology: Uschold and Gruninger propose the use of existing ontologies in the ontology capture or coding or both the processes. • Phase 4- Evaluation: Uschold and Gruninger agree that evaluation of produced ontology is vital and refer us to other related research done in the same domain. • Phase 5- Documentation: Similarly, on the issue of documentation for ontology, they refer to the documentation facilities supported by ontolingua and the KSL ontology editors that they have used.

3.8.2 Gruninger and Fox Method

(Gruninger & Fox 1995) propose a more formal design approach as compared to Uschold’s skeletal method. They used their methodology to design more formal and 58 3 Ontology and Information Systems extensive ontologies like the TOVE ontology(Fox 1992). (The TOVE is a set of formal ontologies for different aspects of the business enterprise like the Resource Ontology, Time ontology etc).

Fig. 3.4. Gruninger and Fox Design Methodology

Figure 3.4 illustrates the steps in the proposed design methodology by (Gruninger & Fox 1995). The various steps that they have proposed are:

1. Capture of motivating scenarios: These are the use case scenarios or problems that arise from a given situation. In the case of ontologies, these scenarios motivate and guide the design of the ontology. Any ontology design should start by describing one or more such motivating scenarios and the intended set of solutions for the problems presented in the scenarios. 2. Formulation of informal competency questions: The competency questions are based on the motivating scenarios and are visualized as expressive requirements that are represented as questions. The ontology must be able to represent these questions using its terminology and characterize its answers using the axioms and definitions. These competency questions are also means to evaluate the ontological commitment of the designed ontology. Detailed examples and explanations of such competency questions may be referred to in the TOVE ontology suite(Fox 1992). For example, in the organization ontology, they have some informal competency questions like: (i) What activities must a particular role perform? (ii) In order to perform a particular activity, whose permission is needed? (iii) What goals is an agent committed to achieving? 3. Specification of the terminology of the ontology within a formal language: Once the informal competency questions have been posed then the terminology identified must be specified using first order logic. This is equivalent to the ‘coding’ phase proposed in the Uschold and Gruninger’s method discussed earlier. This entails first formulating an informal ontology by extracting a set of terms based on the competency questions and the scenario which act as a basis for 3.8 Ontology Design Methodologies 59

specifying the terminology in a formal language. Thereafter, specifying the terms in chosen formal ontology representation language to get a formal ontology. 4. Formal Competency Questions: Gruninger and Fox suggest the formulation of formal competency questions using the terminology now defined in the ontology designed at the end of the previous step. This is necessary, according to them, to evaluate the ontology and claim that it is adequate. The importance and role of competency questions is further discussed in (Gruninger & Fox 1994). 5. Specification in First-Order Logic- Axioms: Finally Gruninger and Fox propose that the axioms specifying the definitions of concepts and their constraints must be defined using first order logic. Gruninger and Fox state that simply defining a set of objects alone or proposing a set of ground terms does not constitute ontology. Axioms MUST be provided to define the semantics of these terms. 6. Completeness Theorems: Finally, they recommend the formulation of completeness theorems that define the conditions under which solutions to the competency questions put forward may be deemed as satisfied.

Thus we see that Gruninger and Fox, though methodical is also strict and formal. It requires that the information system designer be well versed with formal logic languages. As we have discussed earlier, an information system application may not need such high degree of formalism. For example, if the targeted use was for human understanding, then coding the ontology in highly machine-readable ﬁrst order logic is counterproductive.

3.8.3 Noy and McGuinness Method

A practical handbook like design approach has been provided by Noy & McGuinness (2001). However this approach is more like a user manual for a ontology to be designed specifically using the Protégé ontology editor. In simple steps they illustrate the process of capturing the concepts, the slots and the role restrictions. But, on analysis, we see that their basic design methodology is similar to that proposed by the Gruninger-Fox methodology or Uschold-Gruninger Method. Noy and McGuinness have proposed a knowledge engineering method for building ontologies. They advocate an iterative and refinement process and have proposed three fundamental rules for the ontology developer to help him in design decision process, as quoted below:

1. “There is no one correct way to model a domain. There are always viable alternatives.” 2. “Ontology development is an iterative process.” 3. “Concepts in the ontology should be close to objects (physical or logical) and relationships in your domain of interest. They are most likely to be nouns (objects) or verbs (relationships) in sentences that describe your domain.” 60 3 Ontology and Information Systems

They provide a step-by-step instruction for the user to design the ontology using the Prot´eg´e 4 ontology editor. They directly implement the ontology in to classes (concepts), facets (constraints) and properties (relationships). A short summary of the main steps listed by them is given below:

• Determine the domain and the scope of the ontology. They adopt the competency questions idea as suggested by Gruninger and Fox (1994). • Consider reusing existing ontologies. Noy and McGuinness advocate that the designer should look at other available ontologies even though they may be committed to some specific application or may be coded in some other knowledge representation form. They suggest the use of other similar ontologies in Protégé which can be readily imported and modified. • Enumerate important terms in the ontology. They begin by identifying key concepts and terminologies relevant for the domain. • Define the classes and the class hierarchy. In contrast to the middle-out approach proposed by Uschold & Gruninger (1996), they propose a combination of the top down and bottom up approach. That is, they begin with some top level concepts and a few specific concepts. Thereafter they propose to relate these. Next, they build around the central concepts and add more middle-level concepts. In Noy and McGuinness’s view none of the three approaches, top-down, bottom-up or middle-out have any significant advantage and that the final decision depends upon the domain expertise of the developer. • Define the properties of the classes-slots. Next Noy & McGuinness (2001) suggest that the designers add properties (characteristics) to the identified classes(concepts). • Define the facets. The next step is to identify the facets of each of the properties. For example, the cardinality restrictions, value type, allowed classes etc. • Create instances. The final step is to populate the ontology by creating individuals (instances).

As we see, Noy and McGuinness method is simple, explicit to follow for an information system designer. The only disadvantages are that it is not implementation tool independent. Also conceptual model assumptions are implicit in the implementation. Protégé is a user friendly environment, but still the ontology is not readily communicable to non- Protégé users or non-ontology experts.

4 Prot´eg´e is an open source ontology editor and knowledge base framework maintained by Stanford University. Currently it is 20 years old and has a growing user community of over 75000. Several plug-ins are developed open source. http://protege.stanford.edu/ 3.8 Ontology Design Methodologies 61

3.8.4 UPON

The fourth ontology design methodology which we review here is the UPON (Uni- fied Process for ONtology building) proposed by A.Nicola, M Missikoff et al (2005). Their process builds on the accepted Unified Process and uses UML. Thus this design methodology is not unfamiliar to designers already familiar with the unified process for designing. In figure 3.5, we see a summarized overview of the different phases in the ontology building process. UPON makes use of domain experts and knowledge experts in varying degrees throughout the development life cycle.

Fig. 3.5. UPON

Some of the other salient features of UPON are:

• Use Case Driven: That is, the first input is the setting up of storyboard-like scenarios and use cases from the domain of discourse. • Iterative: The different phase of the design methodology is followed iteratively, starting from crude details and refining successively to get specific aspects of the domain. • Incremental: The ontology can grow in steps and is flexible to accommodate new information gathered from new scenarios. 62 3 Ontology and Information Systems

The design methodology closely follows the uniﬁed process and has the following phases:

• Inception Phase. Requirement capturing and modeling the use cases. • Elaboration Phase. Analysis of requirements and fundamental concepts are identified and loosely captured. • Construction Phase. Based on the loosely identified concepts a skeleton for the ontology may be designed. Successive iterations of the first three phases, will lead to refinement and a more stable version of the ontology ultimately reached. • Transition Phase. the ontology is subjected to rigorous testing, documentation and finally released for public use.

They have proposed detailed strategies for requirement workﬂow, analysis workﬂow, capturing and modeling phase etc in (De Nicola & Missikoff 2005).

3.8.5 METHONTOLOGY

The ﬁnal design methodology that we would like to review here is that of METHON- TOLOGY (Fernandez et al. 1997) that is used for building ontologies from scratch or from other existing ontologies or by a process of re-engineering. Till now, the ones we have reviewed basically deal with designing ontologies from the scratch, that is no previous versions or knowledge base or data model exists. Also, these methodologies are not explicit on how the ontology can be further modiﬁed or evolved. Several of the steps proposed by Fernandez et al. (1997) are similar to those of Uschold & Gruninger (1996) or to Gruninger & Fox (1995). But notable difference is their stress on the evaluation and documentation steps. METHONTOLOGY supports an evolving ontology life cycle unlike the others that support top down, bottom up, or middle out approaches. Figure 3.6 from Fernandez et al. (1997) summarizes the different phases of the ontology life cycle; Each phase consists of activities that pass through a number of states that we discuss in detail shortly. Fernandez et al. (1997) advocate that:

• Phase 1 Planify: The designer should plan the entire development process like the tasks, time and resource allocation etc. • Phase 2 Speciﬁcation: Just as one never starts a trip without knowing the destination and purpose for the travel, the designer should never start the ontology design and development process without establishing the purpose and scope of the ontology. Fernandez et al. (1997) propose writing down formal or informal questions and answers to establish the purpose and scope which is similar to the competency questions phase as recommended by Gruninger & Fox (1994) and Uschold & Gruninger (1996) for formal and informal competency questions respectively. 3.8 Ontology Design Methodologies 63

Fig. 3.6. METHONTOLOGY: Constituent activities and their states

• Phase 3: Acquire existing Knowledge: They also advocate the use of existing knowledge bases and knowledge acquisition using techniques as proposed by Uschold & Gruninger (1996). This phase is vital if the designer has to acquire ample knowledge about a domain. This also ensures that a degree of consensus on the domain being captured is already in built. • Phase 4: Conceptualize: Following knowledge acquisition, the designer needs to conceptualize the knowledge using some conceptual knowledge modeling technique as also proposed by Gomez´ -Pérez et al (1996). We describe their conceptualization method shortly. • Phase 5: Formalize: The next step recommended can be quoted as “To transform the conceptual model into a formal or semi-compatible model, you need to formalize it using frame-oriented or description logic representation systems.” Thus, we see that each of the ontology building methodologies that we have reviewed so far all have different chosen representation languages. • Phase 6: Integration: Ontologies are intended to be reuses therefore Gomez-´ Pérez suggest the integration of relevant ontologies as possible. Farquhar and colleagues (1999) have identified four kind of relationships between ontologies that have been integrated: inclusion, polymorphic refinement, circular dependencies and restrictions. Other ontology mapping or integration methodologies have been investigated by Bergamaschi et al. (1998). Semantic integration of ontologies has been a contemporary research topic for many researchers like Kashyap & Sheth (1998). • Phase 7: Machine Readable: To make the ontology ‘machine-readable’ we need to select the formal machine process able implementation language. • Phase 8: Evaluation: Gomez-P´ érez, Juristo & Pazos (1995) now stress the need to evaluate the ontology designed, so that to rule out any erroneous definitions 64 3 Ontology and Information Systems

and discrepancies in the ontology. They have proposed techniques for evaluating ontologies. • Phase 9: Documentation: Thereafter, they recommend that proper documentation is vital as in any software development project, not only for easy reusability, modiﬁcation, but also for conﬁguration management and change traceability. • Phase 10: Maintenance: Finally, they recommend that ontology once designed and developed cannot be forgotten, it needs to be constantly maintained.

We have looked at how the METHONTOLOGY process can aid the design of ontology building from scratch or through re-engineering from existing knowledge bases. METHONTOLOGY builds on top of the Uschold’s skeletal method as well as Gruninger and Fox method. It takes into account software engineering principles as well. It has been tested on diverse domains like chemical ontology, legal ontology (Corcho, Fernandez, Gomez-P´ ´erez & Lopez-Cima´ 2005) etc. But, notable for this research is their conceptualization technique, as summarized in section 3.8.6.

3.8.6 Conceptualization in Methontology

In the conceptualization phase, Methontology recommends to “structure the domain knowledge in a conceptual model”. Of all the methodologies surveyed so far, this is the ﬁrst one to recommend conceptual models. The activities to be carried out are as follows:

Fig. 3.7. Intermediate conceptualizations in METHONTOLOGY 3.9 Relevance of Chapter 65

• Build a complete ‘Glossary of Terms’ (GT). The terms include nouns, verbs, concepts, instances properties etc. The designer should gather all potentially useful information about the concepts and their meanings. • The second step is to group the gathered terms in the GT as concepts or verbs. • For each set of closely related concepts, the designer should build a ‘Concept Classification Tree’ is to be built following guidelines as prescribed in Gomez-´ Pérez, Fernandez & de Vincente (1996) and for the related verbs a verb diagram is suggested as per the proposal of Vincente 5. Figure 3.7 illustrates an example of the intermediate results at this stage of the conceptualization. • A Data Dictionary should be designed that collects all the concepts and their definitions, meanings, attributes, instances etc; a table of instance attributes should provide information about the attributes and its values; tables of class attributes to capture the concepts and not their instances; table of instances to capture the instances; and attribute classification trees that graphically display attributes and constants as per their inference sequence, the sequence of formulas to be executed and so on. • Similarly the set of verb diagrams include a verb dictionary- to express the meanings of the verbs in a declarative manner; tables of conditions that specify a set of conditions to be satisfied like preconditions for actions ; a table of formulas and a table of rules for formula and rule description.

We note that Methontology introduces the role of conceptual modeling in the design of ontologies. Conceptual modeling has been acknowledged to be an integral part of information system design. We assume that most information system designers today would be familiar with conceptual modeling in one form or the other, be it data modeling, information modeling, mindmaps etc. There are different forms, methods, techniques and representation languages for conceptual modeling. In the next chapter, we review some of the relevant background of conceptual modeling and discuss those that are of relevance to this particular research.

3.9 Relevance of Chapter

In this chapter, we began with a historical overview of ontology as investigated in different disciplines. Thereafter, we have reviewed some of the salient features of ontology, its design, approaches and current state of the art design methodologies in Information Systems. As stated earlier, conceptual modeling forms the third vital

5 Vicente, A; Concepualizacion de verbos en ontologas de dominio. Tsis de Master en Inge- niera del Conocimiento. Facultad de Informatica. Universidad Politcnica de Madrid. 1997. However, this publication is not in the English language and we could not determine its contents or applicability. 66 3 Ontology and Information Systems research domain of interest to this research. In the following chapter, we shall review some of the key research from conceptual modeling. O 4

Conceptual Modeling

In the previous two chapters we have looked at two of the three main fields of related theory and research, namely, Knowledge Management and Ontology. As stated, our interest in capturing and representing domain knowledge is based from an epistemological perspective. Our belief is that domain knowledge can be viewed as a mental model by an Information Systems designer or a knowledge engineer or an ontology designer. This is one view of a possible world as proposed by Haack (1978). We have seen the proposals of Sowa (1999, 1976) on the constitution of a knowledge representation. Davis et al have explored the different roles a given knowledge representation can have. Every representation language has its own coding bias. Every targeted information system application has its own implementation specific details embedded inside it. The epistemic domain knowledge is the nucleus of a knowledge representation. We would like to separate this abstract mental model to be reused in different applications, by different designers, for different purposes. This mental model of the possible world description is what we refer to as a conceptual model. Conceptual Modeling is, thus, the key link between complex ontological formalisms on one hand and data-centric Information Systems on the other. In this chapter we begin by exploring the concept of ‘conceptual models’. Then we move on to a historical overview of different conceptualization approaches used in Information Systems. We focus specifically at the Entity-Relationship modeling approach since it is the foundation for the RDF Tuples conceptualization of ontology today. We look at conceptual modeling languages, criteria and extensional and intensional conceptualization. Next we explore the role of conceptual patterns and their uses. Our research revolves around conceptual models and their use as patterns. Specifically we analyze different types of semantic relationships, hence we look at some existing research around similar theme. 68 4 Conceptual Modeling

4.1 Conceptual Model

A conceptual model is defined as an abstract (mental) model of some part of reality. A conceptual model describes the key concepts, their relationships. A more explanatory definition may be given as: An abstract model (or conceptual model) is a theoretical construct that represents something, with a set of variables and a set of logical and quantitative relationships between them. Models in this sense are constructed to enable reasoning within an idealized logical framework about these processes and are an important component of scientific theories. A conceptual data model or conceptual schema as it is also known is defined as:

A conceptual schema, or conceptual data model is a map of concepts and their relationships. This describes the semantics of an organization and represents a series of assertions about its nature. Specifically, it describes the things of significance to an organization (entity classes), about which it is inclined to collect information, and characteristics of (attributes) and associations between pairs of those things of significance (relationships).

Concept

Before we proceed further on our discussion in conceptual modeling, let us ﬁrst examine what do we mean by the term – “concept”. A concept is an abstract idea or a mental symbol, typically associated with a corresponding representation in language or symbology, that denotes all of the objects in a given category or class of entities, interactions, phenomena, or relationships between them. Concepts are also basic elements of propositions. They convey a certain meaning. A single concept may be expressed by n number of representations and languages. For example, the concept of ‘dog’ can be expressed as dog in English, hund Swedish, chien in French and so on. Thus, concepts are independent of the representation language, because they have identical meaning. Conceptualization is the realization or emergence of concepts.

Historical Background of Concepts and Conceptualization

John Locke, the 18th century English philosopher, put forward a theory of ‘general idea’ that was to be created by abstracting, or removing the common characteristics from several particular characteristics. For example the concept ‘dog’ is an abstraction of the general idea that a dog is a collection of characteristics common to a Labrador, a Bulldog, and a Poodle. 4.2 Conceptual Modeling Methods 69

Immanuel Kant (1800) is his discussions in Logic, talks about a posteriori and a priori concepts. The former is a general representation of non-speciﬁc thought that is common to speciﬁc perceived objects. A priori concepts are based on understanding of phenomenal objects and gives rise to categories. To quote Kant,

“The logical acts of the understanding by which concepts are generated as to their form are: (1) comparison, i.e., the likening of mental images to one another in relation to the unity of consciousness; (2) reflection, i.e., the going back over different mental images, how they can be comprehended in one consciousness; and finally (3) abstraction or the segregation of everything else by which the mental images differ. In order to make our mental images into concepts, one must thus be able to compare, reflect, and abstract, for these three logical operations of the understanding are essential and general conditions of generating any concept whatever. For example, I see a fir, a willow, and a linden. In firstly comparing these objects, I notice that they are different from one another in respect of trunk, branches, leaves and the like; further, I reflect only on what they have in common, the trunk, the branches, the leaves themselves, and abstract from their size, shape, and so forth; thus I gain a concept of a tree.”

-Logic, chapter 6 Kant (1800)1 Kant’s quote above summarizes the essence of the current research. Its about how we view the domain from different perspectives, how we reﬂect and abstract out that we wish to communicate to others; be it human, machine or applications.

4.2 Conceptual Modeling Methods

Now when we are talking about conceptual models, we should look at different domains where concepts are modeled, albeit in different contexts and for different purposes:

Data Models: In computer science, data modeling is the process of creating a data model by applying a data model theory to create a data model instance. A data model theory is a formal data model description. In Data models, we structure and organize data into logical, physical schemas targeted for representation and storage in databases. Object Relationship Modeling (ORM): Object-Relational mapping (aka O/RM, ORM, and O/R mapping), is a programming technique for converting data between incompatible type systems in databases and Object-oriented programming

1 Immanuel Kant’s original work Logik was published in 1800, the current excerpt is from the translation published in 1988, translated by Robert S Hartmann and Wolfgang Schwarz 70 4 Conceptual Modeling

languages. In effect, this creates a ‘virtual object database’ which can be used from within the programming language. Object Role Modeling: Object-Role Modeling (ORM) (Nijssen & Halpin 1989) sim- plifies the design process by using natural language, as well as intuitive diagrams which can be populated with examples, and by examining the information in terms of simple or elementary facts. By expressing the model in terms of natural concepts, like objects and roles, it provides a conceptual approach to modeling. Its attribute-free approach promotes semantic stability. ORM evolved from the Natural language Information Analysis Method (NIAM, also known as aN Information Analysis Method) and Binary Relationship Modeling, which were developed in Europe in the mid-1970s. Dr.Terry Halpin provided the first formalization of Object-Role Modeling(Halpin 1998). Object Role Modeling (ORM) is a method for modeling and querying an information system at the conceptual level, and mapping between conceptual and logical (e.g. relational) levels. Entity Relationship Modeling: As explained earlier, databases are used to store structured data. One of the techniques for designing the afore mentioned data models is called Entity Relationship Modeling (ERM). It has a graphical representation and is also a type of conceptual data model. The first phase of information system design, that is requirement analysis uses ERM to describe information needs. Chen (1976) first introduced ER models in 1976, which has since then been the foundation for many of today’s software analysis and design methodologies. The UML modeling language traces its foundations to the ER model proposed by Peter Chen. It is also the starting point for object oriented design as well as the Semantic Web. Therefore, we shall review the ER modeling as conceptual models in section. Knowledge Representation: As we have already seen, knowledge representations within the AI and cognitive science field have laid much emphasis on the representation of knowledge. There are different KR languages, one of them being graphical conceptual models as well. One such KR language, Description Logic has been used for conceptual modeling in AI (Borgida & Brachman 2000). Mindmap: A mind map is a diagram used to represent words, ideas, tasks or other items linked to and arranged radially around a central key word or idea. It is used to generate, visualize, structure and classify ideas, and as an aid in study, organization, problem solving, and decision making. Mindmaps are useful in brainstorming sessions to get ideas generated and put quickly on paper, using hand drawn nodes and words. It is similar to semantic nets and topic maps. Ontology: Ontology is an abstract model describing reality. We shall discuss more about ontology in the forthcoming chapter. Conceptual models are used for expressive and intuitive modeling of Information Systems. 4.2 Conceptual Modeling Methods 71

4.2.1 ER Modeling Revisited

The basic constructs of the ER modeling technique, Entity type and Relationship type are based on set semantics theory, and are as such close in ancestry to the basics of ontology. Chen, Thalheim & Wong (1999) have analyzed the future of conceptual modeling, based on its foundational strengths to be in the areas of:

• Active Modeling. • Relationship between Natural Languages. • Conceptual Framework for shareable information services. • Relationships between real world and software world. • Conceptual models as a basis for interoperability. • Conceptual modeling as ﬁrst step for application engineering. • Global communication. • Human Knowledge Interaction.

We do not delve deeply into their discussions in this thesis but refer the interested reader to their paper. However, we would like to point out that several of the above mentioned areas are, in fact, the purpose and aim for the design and use of ontology in information system, as we have seen earlier. Thus, this strengthens our hypothesis that: R Conceptual modeling, especially ER models, are the key to promote the design and development of ontologies in information system. In our case studies we shall look at the use of conceptual models for:

• Human knowledge interaction / foster human understanding • Conceptual models as basis for interoperability / ontologies as interlingua. • Relationship between natural language and machine readable formal representation • As a set of conceptual modeling patterns for application engineering from natural language to ontology

Chen identiﬁes four levels or views of a data model (ﬁgure 4.1):

• Information concerning entities and relationships that exist in our mind. • Information structure - organization of entities and relationships. • Access-path independent data structure. Data structures which are not involved in search queries and indexing. • Access-path dependent data structure. Data structures which depend on the physical architecture of the data model.

For the current research, since we are interested in the use of conceptual modeling for the design and development of ontologies we shall restrict ourselves to the discussion of the ﬁrst two steps mentioned above. 72 4 Conceptual Modeling

Fig. 4.1. Human Knowledge from Different Perspectives

Chen deﬁnes:

• Entity: Entity is a thing that can be distinctly identiﬁed. • Relationship: A relationship is an association between entities. • Role: The role of an entity in a relationship is the function that it performs in the relationship. For example ‘Husband’ and ‘Wife’ are roles of ‘Persons’ in the relationship ‘Marriage’. • Attribute, Value and Value set: Information about the entities and their relationships can be obtained by observation and measurements and can be expressed by an attribute-value pairs. Values can be classed into different value sets. There- fore, an attribute is deﬁned as the function that maps from an entity set or a relationship set into a value set or a Cartesian product of the value sets.

Chen advocates separating the information about entities from information regarding the relationships to identify the functional dependencies between the data. As said, the origin of the ontology modeling principles (within Information Sys- tems context) can be traced back to the ER model. There are minor differences mainly due to the level of abstraction as well as the context in which the conceptual modeling is to be done, like for example:

1. Chen’s ER model was targeted at the data level, and to organize and structure data in databases. Today, we are interested at the knowledge level and to organize and model knowledge in ontologies. 2. The relationships in the ER model, are by deﬁnition functional relationships which associate objects. In ontology, we have more complex relationships which may again be concepts in themselves. As deﬁned in the conceptual modeling, by Boman et al (1997), we have semantics, pragmatics and syntactics to be captured as well. 4.2 Conceptual Modeling Methods 73

But nevertheless, the ER model has several advantages and is not only for ‘data structures’ as has been summarized by Chen (1983) himself:

• ER Model contains more semantic information than the relational model. Chen argues that a relational table following Codd’s rules prescribe neat data structures but afford little or no semantics to the relationships. • ER model has explicit linkage between entities. ER model makes explicit implicit relationships between entities. One of the goals of ontology modeling, is also to make explicit implicit domain knowledge and that includes discovering hidden semantics of relationships between concepts. • ER model has inspired the RDF and XML language speciﬁcation. The Object- Attribute-Value tuple forms the atomic building block for the RDF graphs.

4.2.2 Conceptual Graphs

Charles Pierce (1933) laid the foundation for semiotics in the early 1900s. He also proposed the use of iconic graphs to represent facts, concepts and relationships. Graphs have also been used by others for knowledge representation such as semantic networks (Brachman 1977), conceptual dependency graphs (Schank 1975) and knowledge graphs (Hoede & Willems 1989). Conceptual graphs as a knowledge representation language was introduced by John Sowa (1976). As Sowa puts it,

“Conceptual graphs are not intended as a means of storing data but as a means of describing data and the inter-relationships.”

In conceptual graphs, concept nodes represent entities, attributes, states and events; and relation nodes denote how the concepts are interconnected. According to Sowa, conceptual graphs have at least three identiﬁable advantages:

1. Supporting direct mapping to relational databases. 2. Providing semantic basis for natural language. 3. Supporting automatic inferencing to compute relationships not explicitly mentioned.

At the time Sowa wrote the above mentioned paper, relational databases were the accepted form of data storage and management. But today, given the shift towards Semantic Web and expression of knowledge, we see that conceptual graphs are more suited to describing the ontological conceptualization of our domain. Con- ceptual graphs are therefore an intensional modeling language.(see intensional and extensional conceptual modeling language in section 4.3). To quote Sowa again,

“the meaning of a relation is its intension and the set of all the n-tuples stored in the database is called its extension” 74 4 Conceptual Modeling

We refer the interested reader to Sowa’s paper or his subsequent book (Sowa 1984) for a detailed discussion of the principles, formation rules, notations and usage of conceptual graphs. It suffices for the ongoing discussion to note that the basic primitive in conceptual graphs is a concept. It is denoted by a box containing a sort label. R A conceptual graph is defined as a finite, connected, undirected, bipar- tite graph with nodes of one type called concepts and nodes of the other type called conceptual relations. Conceptual relations represent inter-relationships that exist between concepts and are denoted by circles with labels. They have two arrows, one for the incoming node connection and the other for outgoing node connection.

4.3 Intensional and Extensional Conceptual Modeling

We now briefly summarize the two aspects of conceptual modeling: Intensional and Extensional modeling. In philosophy, intensionality is described as the distinction between denotation and meaning. As Haack (1978) puts it – Intensionality is when substituting a concept with co-referent concepts changes the truth value of the proposition. Extensionality, is when the substitution leads to no change in truth value. For example: The morning star and the evening star are terms used to refer to the same planet Venus. A proposition like: I saw the morning star in the evening is extension- ally the same as I saw the evening star in the evening, while intensionally it is not the same. The distinction between the two lies in the difference between the semantics, connotation and denotation of the linguistic representation. we shall now aim to understand this better in the following subsection before we move further with our discussion on the different conceptual modeling languages. In linguistics, Semantics is the subfield that is devoted to the study of meaning, as borne on the syntactic levels of words, phrases, sentences and sometimes larger units of discourse, generically referred to as texts. The term Semantics (originated from the Greek word semantikos which means – giving signs, significant, symptomatic, from sema– sign) refers to the aspects of meaning that are expressed in a language, code, or other form of representation. Again there are two aspects, the descriptive or the relation that exists between a sign or symbol and the objects that it represents, also known as denotation by some theorists. The other is the more practical implication and use in situations, that is the pragmatics or its connotation. Though the denotative aspect has been well researched in formal semantic, pragmatic and semiotic traditions, the connotative aspects are not as well developed. 4.4 Using Conceptual Modeling for Ontology Modeling 75

4.3.1 Conceptual Modeling Languages

Returning back to our ongoing discussion, Niinimaki (2004) has reviewed and clas- siﬁed conceptual modeling languages in to three classes:

Extensional Modeling Languages:

Like the ER model, extensionality is expressed as the descriptive terminology of the objects, sets of objects in the domain of application. So that the semantic relationships included are only those that exist between the described sets of objects.

Intensional Modeling Languages:

Like those proposed by Kangassalo (1983) based entirely on Intensional relationships between concepts. The concepts are independent of the domain of application. Bunge deﬁnes the intension of a concept as “possibly inﬁnite set of properties and relations contained in the concept”. Kauppi’s (1967) intensional concept theory has been utilized in knowledge representation, especially description logics by Borgida (1995).

Hybrid Modeling Languages:

Conceptual modeling languages that combine both extensional and Intensional features. Description Logics as put forward by Woods (1991) is a classic example of such a hybrid language. It has the ‘T-Box’, or the terminological axioms that are used to express the concept names and the concept deﬁnitions and the ‘A-box’ for the asser- tional axioms where statements regarding the Intensional features like transitivity, symmetric and inverse relations can be expressed. R Given our objectives to make domain knowledge explicit, we need to declaratively express the intentional aspects of the domain. Current standard for ontology representation, Web Ontology Language (OWL) builds on Descriptive logic and also uses Horn Logic for the rules description. There- fore, the machine readable representation language is a hybrid modeling language. Conceptual modeling using ER or conceptual graphs has been the basis for the RDF tuples. Hence, the transition from an extensional to a hybrid modeling language is seen. This research attempts to merge the intensional aspects of the domain into the extensional modeling language itself. Our USP2 Design approach tries to analyze and represent the intensional aspects of the domain using an extensional representative conceptual modeling language like UML.

4.4 Using Conceptual Modeling for Ontology Modeling

There are several advantages of using conceptual models like (based on (Halpin 1998) and (Jarrar & Meersman 2002)): 76 4 Conceptual Modeling

• Conceptual modeling is a semantically rich discipline and support quality check at high level of abstraction. • Conceptual modeling languages provide conceptual constructs like integrity, taxonomy (part of) and derivation rules. The ontological basis of such part of / whole relationships have been investigated by Opdahl, Henderson-Sellers & Bar- bier (2001). • Conceptual schemas were developed to capture the semantics of the application domain. (Wand, Storey & Weber 1999) • Conceptual modeling languages are expressive and usually have graphical notations. • Conceptual models are thus designed to support clarity which is a measure of how easy it is to understand and use. Graphical models are by far easier to comprehend and use. • Conceptual Models are semantically relevant. Semantic relevance requires that only conceptually relevant details need be modeled. Any aspect irrelevant to the meaning (e.g. implementation choices, machine efﬁciency) should be avoided. This is similar to the ontological commitment principle in ontology design. • Conceptual models can be validated. Validation mechanisms are ways in which domain experts can check whether the model matches the application. • It is easy to have multiple levels of abstraction hidden in a single conceptual model. Abstraction mechanisms are ways in which unwanted details may be removed from immediate consideration. • As we have seen in our preceding discussion, conceptual modeling languages are based on formal theory. A formal foundation ensures models are unambiguous and executable (e.g. to automate the storage, veriﬁcation, transformation and simulation of models).

There are some issues on which conceptual models do not match the objectives of ontology modeling but they are the limitations of the conceptual modeling languages rather than the principle of conceptual modeling itself. Jarrar & Meersman (2002) point out aptly that conceptual models are typically intended for use during design phases and not at run time while ontologies are intended for use at run time in applications. The second difference that they point out is that conceptual models are not application-independent models as are ontologies. To reconcile these two differences, they introduce, ﬁrst a conceptual markup language based on ORM (ORM-ML) and for the second, they propose DogmaModeler as an ontology engineering tool. On the second issue of application independent development of ontology, there is a clash between intended or expected tasks to be solved at hand (that is the purpose for which the ontology is being developed) versus the need to keep the ontology 4.5 Conceptual Modeling Patterns 77 conceptualization independent of the same purpose. As Jarrar & Meersman (2002) put it:

“In the problem solving research community, this issue is called the interaction problem, which inﬂuences the independency of the problem-solver’s domain.”

We agree with Jarrar and Meersman that conceptual data schema and ontologies are similar to each other and that reusing conceptual modeling techniques is advantageous. Conceptual models have been accepted as semi-formal type of ontology by Uschold & Gruninger (1996). To conclude we agree with Jarrar & Meersman (2002) in their observation:

“.... Reusing conceptual modeling techniques for ontology engineering is ultimately beneﬁcial: the large set of existing conceptual modeling methods, graphical notations, and tools can make ontologies better understandable, and easier to adopt, construct, visualize, etc. Furthermore, legacy conceptual schemes can be mined and/or ontologized.”

4.5 Conceptual Modeling Patterns

By now, we agree that conceptual modeling is essential for a sound design and development of an information system. It is natural, intuitive, graphical and thus easy to understand and develop. But foremost of all, different forms of conceptual modeling has existed for over three decades, so most information system designers should be familiar with one form or the other. That supports one of the premises put forward in chapter 1– conceptual modeling is a key to encourage the adoption and use of ontologies in information system. In the previous section, we have also seen the similarity between conceptual modeling and ontology modeling. Conceptual modeling is appropriate for ontology design. However, to build a consistent and clear conceptual model, we need not only a modeling language, but also a method, constructs and rules on how to use these constructs, as proposed by Sowa.(see discussion in section 3.3.3). In this section, we shall lay the foundation for another of this thesis’ premises:-

R Information system designers will ﬁnd ontology designing easier if they are provided with a comprehensive methodology consisting of design and development guidelines, recommendations as well as set of conceptual modeling and analysis patterns.

In software engineering, we are familiar with the use of patterns. Patterns support easy reusability and standardization efforts. The Gang of Four, GOF (Gamma, Helm, Johnson & Vlissides (1994))as they are widely known as, introduced software 78 4 Conceptual Modeling design patterns, in 1994. The main aim is to propose a set of software design patterns for object oriented programming. They have proposed a set of patterns like Creational Pattern, Structural Pattern and Behavioral Pattern.

4.5.1 Design Patterns

A design pattern is a formal way of documenting successful solutions to problems. The idea was ﬁrst introduced by the architect Christopher Alexander (1977) in his book “A Pattern Language: Towns, Buildings, Construction”. Martin Fowler (1997) in his analysis patterns book has further proposed these object oriented patterns targeting the enterprise domain. Some of the patterns introduced by Fowler in his Analysis Patterns book are: Domain Logic Patterns, Data Source Architectural Patterns, Object-Relational-Behavioral Patterns, Object- Relational-Structural pattern and so on. The aim of this section is not to review these patterns by themselves, but to illustrate the utility and acceptability of design patterns in general as a mechanism for easy design and development. Cabot & Raventos (2004) have classiﬁed design patterns in to two categories:

• Conceptual modeling patterns: A conceptual modeling pattern is aimed at representing a specific structure of knowledge encountered in different domain. • Analysis patterns: An analysis pattern specifies a domain-dependent knowledge required to develop an application for a specific users. Ex: patterns for electronic market places.

Cabot and Raventos (2004) hold that Fowler’s design patterns are examples of conceptual modeling patterns, and Fernandez & Yuan’s (2000) patterns correspond to analysis patterns. Geyer-Schulz and Hahsler (2002) hold the view that idea of using a structured writing template for describing the patterns themselves ensures that the patterns are easier to teach, learn, compare, write and use. The original structure for design patterns is to describe context/problem/forces/solution. Geyer-Schulz and Hahsler carry out a detailed semantical analysis for the design patterns and propose a template for the design patterns as: Pattern Name: A name for accessing and identifying the deﬁned pattern. Intent: What the pattern does and what problems it addresses. Viz, the purpose. Motivation: A scenario that illustrates the problem and how the problem contributes to the speciﬁed scenario. Forces and Context: Forces and context that should be resolved by the pattern. Solution: Describe all relevant structural and behavioral aspects of the pattern. Consequences: How the pattern achieves its objectives and any existing trade offs. 4.5 Conceptual Modeling Patterns 79

Design and Implementation: How the pattern can be realized. Known use: Examples of the patterns.

R In this research, we agree and adopt Cabot & Raventos’s (2004) clas- siﬁcation of design patterns. We propose sets of design patterns at both levels as conceptual modeling patterns and analysis patterns, as we shall see later. The use of ontologies as analysis patterns in the requirement and domain analysis phase of Information Systems has been supported by Uschold and Gruninger (1996), Johannesson & Wohed (1998) as well as Geerts & McCarthy (2000). To quote Geerts and McCarthy (2000):

“As an analysis pattern, ontologies specify the objects of interest in the domain and the rules to assemble objects into information structures. In addition, experiences and best practices for the patterns are stored in a knowledge base to be shared and reused. ”

Johannesson & Wohed (1998) also agree that design patterns promote reuse of knowledge, thereby, reducing cost for developing Information Systems. They define the term specification pattern for design patterns to be used in the design stage of Information Systems. They define:

“A speciﬁcation pattern consists of an application independent model of a domain structure,...... a speciﬁcation pattern describes, at an arbitrary level of abstraction, a set of real-world objects, their inter-relationships and the rules that govern their behavior and state.”

We propose generic domain independent models which belong to the category of “conceptual modeling design patterns”, for example the deontic analysis model (based on speech act theory), Event Condition Action Rule analysis model, as well as speciﬁc domain patterns like the adoption of the ECA rule analysis speciﬁc to our military case study domain. We also follow a template like pattern for describing our O4IS design methodology itself as we shall see in chapter 5. But, for now we look at some other related work where events, roles have been conceptualized as entities in conceptual modeling.

Roles as Entities in Conceptual Modeling

Cabot and Raventos use the above mentioned template for describing patterns as put forward by Geyer-Schulz and Hahsler, to describe their Roles as entity types pattern.

1. Pattern Name: Roles as entity types 2. Intent: Representation of roles that entities play through out their life span and control of their evolution. 80 4 Conceptual Modeling

3. Motivation: Roles are useful to model the properties and behavior of entities that evolve over time. Ex: a Person entity may play different Roles at different times and at different contexts, sometimes a student, sometime an employee, sometimes a Musician. 4. Forces and Context: For roles, they identify a set of features for roles like, ownership, dependency, diversity, multiplicity, dynamicity, control, inclusion(recursive), identity and adoption. 5. Solution: For structural aspects of role, they identify it as an entity type and define a relationship between a role entity type and its natural entity type by means of a RoleOf relationship. They use UML 2.0 and OCL 2.0 to represent their proposal and introduce << role-of>> as a stereotype. For the dynamic part of the role modeling, they make use of OCL constraints, for example to represent that a person can only play the role of employee if the person is between the age of 18 and 65: context Employee inv: Self.age>= 18 and self.age <= 65 6. Consequences: Cabot and Raventos analyze the fulfillment of their proposed solution in terms of the forces and contexts identified. They also acknowledge that the limitation of their solution is that the role entity type is considered to exist only between similar natural entity (person) 7. Design and Implementation: They recommend an adapted version of the Role Object Pattern 2 8. Known Uses: Some known uses of roles from other related research in security and workflow areas are cited.

The above “pattern” for describing roles is relevant to us in two ways. Firstly, our realm of research focuses on domain knowledge analysis and representation in Information Systems. As we have already seen the interaction of humans, organizations and enterprises is the subject of interest in such applications. Therefore, the ‘roles’ that different actors or entities play, is one of the fundamental concepts in our domain. Secondly, their adopted pattern for describing and documenting their proposal, makes it easy to understand and reuse, thereby, motivating us to follow a similar, ‘pattern-based approach’ to describe our proposed methodology as well as the conceptual models. Our interest in modeling the procedural and pragmatic aspects of a domain necessitates that we are able to capture and represent the dynamical aspects of a domain as well, such as events, actions, causes and their effects so on.

2 Proposed by Baumer, Riehle et al, The Role Object Model. PLoP 97. Technical Report WUCS-97-34. Washington University Dept. 4.5 Conceptual Modeling Patterns 81

Events as Entities in Conceptual Modeling

Most of the conceptual modeling languages and methods do not model events as entities in themselves. They adopt predominantly an object centric view and follow the object oriented analysis approach. Antoni Olive (2004) has pointed out the advantages to be gained in modeling events as entity types. Events as entity types allow us to model behavioral aspects of our domain. Even though the expression of events as entities is not new and has been proposed since the early 80s, still behavioral modeling has been limited to state transition diagrams, sequence or choreography diagrams. UML languages distinguishes four types of events:

• Call events for the invocation of operations. • Signal events intended for asynchronous communication between objects. • Change events for satisfaction of boolean conditions. • Time events for satisfaction of time expressions.

But UML does not provide constructs for us to represent these at the conceptual level as objects. Olive proposes a method for modeling events as entity types and makes use of UML language constructs such as constraints, derivation types and type specializations. Olive further defines some fundamental primitives for describing events as event types; structural and query event types, Event Characteristics, Event Constraints, and Query Event Effects as briefly summarized below: Structural Events: The state of a domain at some point of time is defined as the set of instances of the relevant entity type and the relationship types that exist in the domain at that time. The state of the domain changes if at a given instant of time, the current state is different from the state it was at time t-1. These state changes are said to occur through Structural Events. A structural event is said to be an elementary change in the population of an entity or relationship type. In UML there are nine different types of structural events identified like create object, reclassify object etc. 3 Domain Event: Is a set of structural events that can be said to constitute a single change in the given domain. Domain events are caused by actions performed in the domain. Domain events can again be external domain event(ex order received from buyer), temporal domain event ( passing of last date for submission of application) or generated domain event (caused by the actions performed by the domain itself, internal events). Query Events: A query event is a request for information and could be external query event when issued by an outside actor or a generated query event.

3 For details see UML Superstructure 2.0, Final Adopted Speciﬁcation. 2003. www.omg.org/ cgi-bin/doc?ptc/2003-08-02 82 4 Conceptual Modeling

Event Characteristics: The characteristics of an event are deﬁned by Olive as the set of relationships in which the event participates. Event Constraints: Describe constraints and conditions that an event must satisfy in order to occur. Query Event effects: The answer to query events are modeled and represented as an effect operation in UML notation associated with the event UML class in Olive’s proposal. Domain Event effects: Similar to the query event effect, the domain event effect is used to describe post-conditions of the result of a set of prescribed structural events. The above is just one effort in the realm of conceptual modeling of prescriptive behavior, rules and dynamics. This illustrates the depth and breadth of the conceptual modeling paradigm. Our second case study, the DCMF Project is action-centric and the focus of the conceptual models presented therein, revolve around the action and events that are allowed to occur around these. Thus, our conceptual modeling methods proposed take in to consideration different approaches like the ones reviewed here, namely the roles as entity types, events as entity types and so on.

4.6 Procedural and Behavior Representation Languages

We have seen the conceptual languages for representing the static concepts of a system or a domain of interest. Dynamic aspects like behavior or processes are usually represented using graphical languages like Data Flow Diagrams (DFDs), Event- Driven Process Chain (EPC) diagrams, UML activity diagrams, petrinets and Business Process Modeling Notation (BPMN) to name a few. We now brieﬂy summarize some of these below:

• A Data Flow Diagram is a graphical representation of the “flow” of data through an information system. It is used for visualizing the processing of data through the proposed information system. DFDs were initially proposed by Larry Con- stantine (1974) as a part of the Structured System Analysis and Design. A data flow depicts processes, data stores, and external entities in a business process. The main notations for the same may be seen in figure 4.2. • Event-Driven Process Chain Diagrams: Event-driven Process Chain (EPC) diagrams were proposed by Scheer, Keller and Nuttgens 4 in the early 90s. The EPC diagram is graphical and easy to understand and is used for depicting the control, flow and organization of events and processes within a business process. Some

4 Keller, G., Nttgens, M., and Scheer, A.-W. (1992). Semantische Prozemodellierung auf der Grundlage ”Ereignisgesteuerter Prozeketten (EPK)” (Rep. No. 89). Saarbrcken: Universitt des Saarlandes. 4.6 Procedural and Behavior Representation Languages 83

Fig. 4.2. Basic DFD Notations of the main components of an EPC include events, functions, organization unit, information, control flow, information flow and logical connectors (OR, XOR and AND) as illustrated in figure 4.3.

Fig. 4.3. Basic EPC Diagram Notations

– Events: Events are passive elements that describe the circumstances under which a function or process works. They are represented as hexagons. – Functions: Functions are active elements that model tasks or activities. They describe transformations that occur from an initial state to a resulting state. Functions are represented as rounded rectangles. – Organization Unit: Organization unit determine the actor or roles within an organization that are responsible for the related function. Graphically they are represented as ellipses with a vertical line through them. – Information, Material or Resource Objects: Objects from the real world are represented as rectangles in an EPC diagram to denote entities that act as input or output to functions. – Control Flow: Control ﬂow arrows connect events and functions or logical connectors in a chronological sequence thus creating local dependencies. – Logical Connectors: In EPC diagrams the logical connections between events and functions are represented by the logical connectors, namely XOR(Branch/ Merge), OR (logical alternatives) or AND (Fork/Join) connectors. 84 4 Conceptual Modeling

• UML Activity Diagrams: UML activity diagrams are one of the five UML diagrams used to represent the procedural flow aspects of an enterprise. The structural diagrams that include the UML class diagram, component and deployment diagrams are used for modeling the static aspects of a system. Behavioral diagrams are utilized to visualize the dynamic aspects of a system. In UML the behavioral diagrams include use case diagrams, interaction diagrams (sequence and collaboration diagrams), state diagrams and activity diagrams. UML activity diagrams are similar to UML state diagrams that model the different states an object can change through. UML activity diagram model workflows and business processes. The entire UML activity diagram is attached to a use case diagram or a class operation, thus connecting to the static aspects of the system. The main components of an UML activity diagram are activity, start state, stop state, transition, decision, synchronization, object flow and object as shown in figure 4.4.

Fig. 4.4. Basic UML Activity Diagram Notations

EPC diagrams follow the process centric modeling approach (the main focus is the processes that are occurring within a system) while the UML activity diagrams follow the object centric modeling approach (the main focus is the objects inside a system). • Petrinets: Petri nets are mathematical representations of discrete systems first introduced by Carl Petri (1962). Petrinets consist of places, transitions and directed arcs between them as depicted in figure 4.5. Places contain tokens. Transitions act upon the tokens when they are fired. They consume the tokens from their input place, complete some processing and produce a predetermined amount of tokens in their output place. • BPMN: Business Process Modeling Notation (White 2004) is currently a standardized modeling notation for representing business processes and workflow. BPMN was developed by the Business Process Management Initiative (BPMI) and is now managed by the Object Management Group (OMG). BPMN is targeted towards all stake-holders from business managers to designers and hence 4.6 Procedural and Behavior Representation Languages 85

Fig. 4.5. Basic Petrinet Notations is graphical and simple to use. The main constructs in BPMN include ﬂow objects, connecting objects, swimlanes and artifacts.

Fig. 4.6. Basic BPMN Notations

– Flow objects consist of events, activities and gateways. · Events are things that happen and are represented by circles. As seen in ﬁgure 4.6 they could be start, intermediate or end events. 86 4 Conceptual Modeling

· An activity (figure 4.6) is a rounded rectangle and is used to represent a task, process or sub processes. · A gateway is a diamond that represents decision points. (see figure 4.6). – Flow objects are connected to each other using connecting objects. There are three types of connecting objects, namely sequence flows, message flows and association as illustrated in figure 4.6. – Swimlanes are used to organize activities that are functionally similar into same visual category. They are depicted using rectangles that contain the flow objects and connecting objects. – Artifacts allow the introduction of more detailed information like the data that may be required in an activity, a logical grouping or annotation of texts to explain the model better. The graphical notations are shown in figure 4.6.

We shall use some of the above representation formalisms later in this thesis when we depict the procedural concept views.

4.7 Relevance of Chapter

In the context of this research, the above discussion is relevant, since, the formal ontology representation language chosen is that of Web Ontology Language(OWL). OWL, as we know, uses DL for describing the Intensional features of the ontology. Therefore, we come to a key issue or goal that has been addressed in this thesis:

If ontology in information system is supposed to be a combination of extensional and intensional representations of concepts and their relationships then how should an Information Systems designer design and develop the targeted ontology?

To address this issue: we propose an uniﬁed semantic procedural pragmatic conceptual design approach which builds on the well known ER Model and guides the designer in capturing the Intensional features, implicit relationships as graphical conceptual models in the ﬁrst step, which are transformable into the formal OWL, DL representations. In the previous two chapters, we have seen (A) the background and theory of Knowledge Management and Information Systems. We have discussed the need for adopting KM principles in Information Systems. (B) We have traced the origin, history of Ontology, from philosophy, linguistics, AI and in Information Systems. We discussed the aspects that would be relevant to ontology design and development in Information Systems. Thereafter, we surveyed some of the contemporary ontology design and development methodologies, architectures and approaches. The aim of this chapter was to introduce the Information Systems designer to some of the basic 4.7 Relevance of Chapter 87 concepts prevalent to day. This chapter, dealt with the domain that overlaps both Information Systems and Ontology, namely Conceptual Modeling. We have looked at what are conceptual models, their utility, and the different approaches. We have motivated the reason why conceptual models would be the ideal cross-link between traditional ER based conceptual models and the ontological conceptualizations. We have looked at the role that design patterns play in the conceptual modeling methods.

O 5

Ontology for Information Systems Design Methodology

In philosophy, ontology is a description of the world ‘as-is’. In the Information Sys- tems domain, this is synonymous with the world ‘as-it-should-be’. That is, in philosophy, ontology is ‘descriptive’ semantics while, in Information Systems, ontology is more ‘prescriptive’ (Smith 2003a). Smith et al (2004) further define ‘endurants’ as entities that exist in full at every instance of time in which they exist. ‘Perdurants’ are defined as entities that unfold themselves in successive temporal phases. Most enterprise and business process ontologies model static concepts, i.e. endurants. Dynamic concepts, i.e. perdurants, such as change or process, need also to be conceptualized in a similar way to facilitate automation of business processes. Aligned with this, Smith (2004) emphasizes a fundamental difference in approach and design of ontology in Information Systems, which he terms as ‘Descriptive Ontology’ and ‘Procedural Ontology’. This has been further strengthened by Roberto Poli (2003) in distinctions of ‘descriptive’, ‘formal’ and ‘formalized’ ontologies. Though many of the fundamental principles of ontology within Information Systems are influenced by the philosophical origin of ontology, ontology in Information Systems symbolizes an established cognitive knowledge. This implies that in addition to the description of the domain concepts, the behavioral and functional aspects of the domain should also be an integral part of the ontology. Thus, ontology for use in Information Sys- tems differs slightly from the philosophical view of an ontology. The question then arises– how do we design and model both the descriptive and the prescriptive aspects of the domain? In this research, we address this dilemma of ontology design and modeling. In particular, we consider conceptual modeling in the realm of Information Systems. The fundamental objective behind conceptual modeling and that of ontology is the same – to conceptualize the domain of interest. Following our discussion in chapter 1.1.3 as well as section 4.4, we believe that conceptual modeling holds the key to a comprehensive knowledge representation of a domain covering all the three aspects as all mentioned by Boman et al. (1997): (a) semantics; (b) syntactics; and (c) 90 5 Ontology for Information Systems Design Methodology

pragmatics. In section 4.3 we have reviewed different types of conceptual modeling languages and the different aspects that they can cover. We have also seen the options available for conceptual modeling of process and behavior in section 4.6. One such language for knowledge representation, Uniﬁed Modeling Language (UML) is being widely used for conceptual modeling. UML class diagrams are effective for capturing the endurants of a domain. UML activity, sequence or choreography diagrams are useful for capturing the perdurants. However, there still remains the issue of modeling both the static and dynamics or behavior of a domain, in an integrated, reusable and generic conceptual model. In this research, we shall aim to use UML as our conceptual modeling language. We now move on to the speciﬁc design choices an Information Systems(IS) designer has to make while designing domain ontologies that capture all the three above mentioned aspects:

i Which concepts are relevant and necessary to be included in the proposed ontology? ii What is the optimum design architecture for the proposed ontology? iii What kind of design strategy is best suited for the given domain and given purposes? iv How to be consistent in the conceptualization of similar categories of concepts? That is, there is a need to avoid subjective bias of the designer, ensuring repeatability and consistency of the design process. v How to match the functional requirements of the targeted Information Systems application with the goals of ontology design? How do these functional requirements inﬂuence the ontology design choices? vi What is the minimum required level of knowledge formalization? vii Which knowledge representation formalism/language to choose? viii Once the above design decisions are taken, how should a designer actually proceed in capturing, analyzing and representing the implicit and explicit domain knowledge? ix What tools, methods, other knowledge sources, models may be chosen to help in the knowledge modeling process?

The above is not an exhaustive list of problems and issues faced by the IS designer today. This research shall aim to answer a few of the above-mentioned issues. Several guidelines, methodologies and approaches have been proposed for: (a) ontology design criteria; (b) ontology architecture; (c) ontology design strategy; and (d) ontology development life cycle, as we have reviewed in the earlier chapter 3. However, the IS designer is still faced with the problem of selecting and choosing from the available state of the art technologies. Additionally, the IS designer may or 5 Ontology for Information Systems Design Methodology 91 may not be well versed in all the disciplines of ontological analysis (as reviewed in chapter 3 above): lexical semantics; philosophy; AI; and linguistics. In this regard, it is not sufﬁcient to just outline the steps to be adopted in a design process as has been done by many of the current ontology design methodologies. The IS designer would need a set of additional models, constructs and methods which can help him/her in effectively carrying out his/her design tasks. Therein, lies the motivation and goal for our proposed Ontology for Information Systems design methodology:- R The Ontology for Information Systems (O4IS) design methodology describes, in detail, the design and development of domain ontologies for use in In- formation Systems, targeting the IS designer. O4IS design methodology also puts forward a number of recommendations for existing methods, algorithms and tools to be used in different steps like the following:

• Proposes a novel multi-tiered architecture for logical demarcation of a domain ontology. • Recommends a dual conceptual representation for domain ontologies in Infor- mation Systems. • Puts forward a new design approach for descriptive and prescriptive domain conceptualization in the USP2 Design (As we shall see later in chapter 6). • Proposes a series of conceptual analysis patterns called Semantic Analysis Rela- tionships (SARs) which are helpful aids in the analysis and conceptualization of implicit domain knowledge.

The O4IS design methodology is the main skeleton which links and holds together all the other above-mentioned constructs, methods and models that are proposed in this research. By the combination and reuse of existing research, available techniques and innovative research, we now present the O4IS design methodology in detail. We begin by introducing the O4IS design methodology in section 5.2, followed by two of our other proposed artifacts in sections 5.3 and 5.4, as shown in ﬁgure 5.1. We shall discuss the other artifacts– the USP2 Design and SARs, etc., in the following chapter.

Fig. 5.1. Chapter Disposition 92 5 Ontology for Information Systems Design Methodology

5.1 Requirements on O4IS Design Methodology

The current research is motivated by all the design methodologies that have been surveyed in this research. However, we have a special inclination towards Methon- tology as being the closest to our proposed O4IS design methodology. They have begun with the notion of conceptualization, while we have followed that road and completed the end result. Our ontology design methodology is driven by conceptual modeling design principles, techniques and approaches as we shall see later. How- ever, we advocate the use of graphical conceptual models not as an intermediary representation but as the final ontological representation that can be translated into other machine-readable formalisms. Methontology is also easy for novice beginners to adopt as many of their recommendations are similar to database conceptualization and design. However, they use mainly textual or tabular text representations. While their idea on the verb diagram analysis is sound, we found that we could not make much use of it since the document describing the rules for the verb diagram was not accessible and in Spanish (to the best of our knowledge). From Uschold and Gruninger’s skeletal method(section 3.8.1), we adopt the simplicity of starting from defining scenarios. We are also motivated by the RUP oriented UPON (section 3.8.4) in the initial knowledge acquisition phase. UPON is the only methodology (amongst those listed in this research) which explicitly mentions the roles of a domain expert and the Information Systems designer. We have used and found Noy and McGuinness’s guidelines (section 3.8.3) practically useful and efficient in introducing the world of ontology building to a novice, specially if the IS designer is using the Protégé ontology editor. Though all of them suggest defining the scope and purpose for the ontology, they do not explicitly cater to functional needs of the targeted application. That is, some of the design choices to be made are governed by the functional requirements or the domain specific informational needs. R In our practical experience in several domains, we saw that not a single one of the above mentioned ontology design methodologies was satisfactory for meeting all the specific requirements for designing ontologies for use in targeted Information Systems applications. In some cases, a blend of one or two was a match, and in others more than that. This was the motivation for us to propose our own design methodology that could cover almost all of the requirements, namely:

• Design methodology should be easy for a non-ontology expert IS designer to follow. • Design methodology should be adaptable to cater to different targeted application needs. • Design methodology should be comprehensive and should be able to capture semantics, pragmatics and the dynamic behavioral aspects of the domain. 5.2 Introducing the O4IS Design Methodology 93

• Design and the subsequent ontology should make domain assumptions explicit. • Methodology should aid the designer in different identiﬁed stages by examples, patterns, models or guidelines. So that it is clear to a designer how the design methodology is intended to be used. • Domain conceptualization should be reusable, shared and understandable to human users as well as processable by machines capable of supporting inferencing. • Domain conceptualization should be free of any encoding bias, including knowledge representation and the subjective bias of the designer.

5.2 Introducing the O4IS Design Methodology

Some of the common functional design requirements of an Information Systems application may be summarized as: ﬂexibility; reusability; easy maintenance; rapid development life cycle; extensibility; traceability; machine readability; support evolution and shared understand ability (Kabilan & Mojtahed 2006b). We now present our proposed methodology for ontology conceptualization, design and development targeted at IS designers with little prior expertise in ontology design and development. As seen in ﬁgure 5.2, our proposed Ontology for Information Systems (O4IS) design methodology consists of ten steps or phases in the design and development of domain ontologies as listed below:

• G1: Establish the scope of the domain. • G2: Establish the targeted users, applications, and functional requirements. • G3: Choose ontology architecture:- physical and logical. • G4: Choose ontology development approach. • G5: Choose level of ontology representation. • G6: Choose knowledge acquisition methods and tools. • G7: Knowledge analysis:- conceptualize the domain ontology. • G8: Knowledge representation:- implement the domain ontology. • G9: Evaluate, assess and verify the domain ontology. • G10: Use, maintain and manage the domain ontology.

In addition to this design methodology, we also propose a number of artifacts to be used in different steps, like the multi-tiered architecture for the logical structure of domain ontologies, dual conceptual representation, semantic analysis representations and the Unified Semantic Procedural and Pragmatic Design, as shown in the same figure 5.2. We will now go through the details of O4IS design methodology. Thereafter, we discuss the multi-tiered architecture in section 5.3, the Dual Con- ceptual Representation in section 5.4. The USP2 Design and the Semantic Analysis Representations are discussed in chapter 6. We now first describe the presentation 94 5 Ontology for Information Systems Design Methodology

Fig. 5.2. The Ontology for Information Systems Design Methodology 5.2 Introducing the O4IS Design Methodology 95 format for our O4IS design methodology and thereafter we present the detailed methodology description.

5.2.1 Template for describing the O4IS Design Methodology

As stated earlier in section 4.5.1, we follow a template-based approach similar to those adopted by the design patterns (Gamma et al. (1994), Fowler (1997)) to describe the proposed methodology. The template for the O4IS design methodology is as follows: Name: Gives the step number and name for the guideline /recommendation. It also gives the intent for that particular step. Input: Lists and describes the necessary input information, requirements and tools for carrying out the described step. Output: Expected output at the end of this step. Note that all steps may be carried out iteratively till a satisfactory output is attained. Procedure: Describes and discusses the procedure to be followed in this particular step so that the design and development may progress from the input state to the output state. Illustration: A running case scenario is followed through out the proposed ten step design methodology and intermediary step results are discussed at relevant stages. Under the purview of some of the individual stages, we discuss and make use of other conceptual modeling and/or analysis patterns. Details of each such pattern and its associated methodology are included separately in the following sections.

5.2.2 G1: Establish the scope of the domain

Just as in any software design methodology, the designer is required to establish the scope and constraints for the domain which is to be captured in the proposed ontology. By universe of discourse we mean the current domain(s) in which we are interested in, that is the domain which is to be described by the proposed ontology. It could be a single domain or a combination of domains as the targeted use may be. Given that ontology prescribes to the open world assumption, it is important to identify the boundary of the domain to be investigated. Input: Domain of interest, a purpose or problem to be solved through the use of the developed ontology. Output: A set of requirement criteria, both functional and non functional,for the targeted application. Procedure: Begin by identifying the domain which the proposed ontology is to be used in, that is the context of application. Identify the required functionalities 96 5 Ontology for Information Systems Design Methodology of the application. Identify the main features of the domain to understand how it relates to other domains. Illustration: For example, if the domain of application is that of a car rental and leasing enterprise, then we have the identiﬁed contexts as that of the customer, the objects of interest, namely the vehicles and the price at which they are to be rented and so forth. As seen in ﬁgure 5.3, the scope of the proposed ontology should be an overlap of all these contexts.

Fig. 5.3. Establishing Domain Scope.

5.2.3 G2: Establish the targeted users, applications, and functional requirements

We recommend that the designer lists the projected end uses, their requirements and targeted users. Input: The identiﬁed scope of the ontology and its application context, the people who are the targeted users, domain experts from the concerned domain. 5.2 Introducing the O4IS Design Methodology 97

Fig. 5.4. Establish the Applications and Users of the Domain.

Output: A set of application purposes, scenarios for use, user specific functional requirements. These may be described in natural language or use case diagrams. Procedure: Identify the targeted user groups, their profiles and their usual expertise with the domain. Identify the typical usage scenarios. It is also advised to identify the exceptions that may occur, since these would also have to be handled in the long run. Illustration: For example, in figure 5.4 we see the perspective of the customer in a car rental enterprise scenario. Similarly we would have use cases for the entrepreneur like the vehicles and their leasing prices. The targeted users of an ontology based application for this car rental service would be either the customer or the entrepreneur. Note that both have different application requirements. 98 5 Ontology for Information Systems Design Methodology

5.2.4 G3: Choose ontology architecture: physical and logical

In this step we now decide on the appropriate architecture for the proposed ontology. Input: System requirements, application environment, current ontology design architectures, proposed multi-tiered architecture for logical architecture. Output: Selected appropriate physical and logical ontology architecture suitable for the particular application.

Fig. 5.5. Types of Physical Architecture for Ontology

Procedure: Choose a physical architecture from (see figure 5.5 for illustration): (i) single ontology for a central application; (ii) multiple local ontologies for distributed applications; and (iii) a hybrid ontology for distributed application but yet supporting interoperability. For the logical architecture design for domain ontology, we recommend the multi-tier ontology structure as shown in figure 5.6. More details regarding the multi-tier ontology are discussed in section 5.3. Illustration: For our simple case scenario, we could choose to have a single ontology as the physical ontology architecture. However, for the logical ontology, we choose a multi-tiered structure, where we reuse existing ontologies like the upper OPENCYC ontology 1 where concepts like Transportation, TransportationEvent, TransportationDevice,Vehicles, and Passenger, etc., are defined. We can even make use of other car rental ontologies like the one defined in a demo using a car- rental application 2. But for simplicity’s sake, we assume that we will develop our car ontology from scratch making use of an generic upper ontology like OPENCYC or SUMO for inspiration. We will also use a domain ontology like the Enterprise Ontol-

1 See Details at http://www.cyc.com/cycdoc/vocab/transportation-vocab.html 2 See details at http://interchange.mit.edu:8080/gcms_v4/Car/index.html 5.2 Introducing the O4IS Design Methodology 99

Fig. 5.6. Multi-tiered Domain Ontology Architecture

ogy for providing us with concepts from the business aspects like hiring, renting, and payment.

5.2.5 G4: Choose ontology development approach

In this phase, the designer begins to make decisions on how he would start his analysis and design work of the domain ontology. Input: Current approaches for ontology design and development. The available choices are: (i) Top-Down approach; (ii) Bottom-Up approach; and (iii) Middle-Out approach. A Middle-Out design approach is best suited as proposed by Gruninger & Fox (1995) as it supports rapid, easy development and reuse of existing sources. We have discussed further on the advantages of this approach in section 3.7. Output: Based on convenience, scale and scope of the proposed ontology, one of the above-mentioned three approaches is chosen. Procedure: If the domain is new and no other ontology for the same or similar domain exists, then we suggest that a bottom up approach is appropriate, since one can begin by studying the individuals and generalize them to form the generic concepts. If the domain is well understood and documented then, it is easier to start with the top most generic concept that we wish to include in our proposed ontology. Illustration: For example, for our car rental scenario, the most generic concept that we are interested in is ‘customer’, then we can further specialize to identify ‘regular customers’, ‘long term special customers’, ‘private customers’, ‘international customers’ and so on. If we need to support interoperability with other similar car rental agencies, then we could choose the middle out approach, where we begin by identifying the ‘customer’, but thereafter also map to existing ontologies like Enterprise ontology, to identify ‘customer’ as an ‘actor’. 100 5 Ontology for Information Systems Design Methodology

5.2.6 G5: Choose level of ontology representation

Once we have identiﬁed the scope, and know the basic architecture and development approach, we need to decide what representation formalism is required for the application context at hand. For example, if the purpose is only for human understanding and communication, then a complex formal knowledge representation is not warranted. Input: Uschold & Gruninger (1996) have classiﬁed ontologies depending upon their formality and complexity of knowledge representation formalism as belonging to the following major categories: Highly informal; Semi-informal; Semi-formal; or Rigorously Formal (see details in section 3.4) and the other input is our proposed Dual Conceptual Representation. Output: Selected representation level for the proposed ontology.

Fig. 5.7. Dual Conceptual Representation for Domain Ontology

Procedure: We propose to model the domain of interest in two phases as illustrated in figure 5.7. In the first phase we capture the domain knowledge as a series of UML conceptual models, thereby conforming to the semi-formal ontology type. These are useful for human understanding, promote rapid reuse amongst users, and can be readily transformed to formal ontologies. In the second phase, these UML conceptual models are transformed in to machine-readable formal ontology representations using Web Ontology Language (OWL). R This Dual Conceptual Representation of the domain, is a novel approach as compared to other contemporary ontology design methodologies, to the 5.2 Introducing the O4IS Design Methodology 101 best of our knowledge. We present the same in detail in the section 5.4. We propose that even if the targeted application requires rigidly formal ontology implementation, the designer should always analyze and represent the domain knowledge as conceptual models first and thereafter implement these conceptual models as formal ontology. Illustration: For our car ontology example, we would like to make a knowledge base that we can query to retrieve meaningful information. Hence, we choose to design a formal ontology. But at the same time, we would also like to explain and show our conceptual model to other potential customers and business partners.

5.2.7 G6: Choose knowledge acquisition methods and tools

In this phase, the designer makes a choice regarding the process of how the domain knowledge is to be collected. Input: Knowledge acquisition methods for manual, semi-automatic or automatic extraction of knowledge and information from natural language text, and web pages, etc. Informal knowledge capture guidelines as suggested by Uschold and Gruninger. From Uschold (1995) we also adopt the idea of investigating and capturing the domain first in natural language. Or the designer may choose the storyboard sketch option as put forward in UPON (De Nicola & Missikoff 2005). Any of these methods are suitable for the collection of information. Other automatic or semi-automatic knowledge extraction techniques and tools may also be used. But currently tool support is still primitive and hence we recommend that the designer chooses an informal storyboard method of collecting information from subject matter experts, that is the domain experts, the targeted users etc. As a part of our proposed Unified Semantic Procedural and Pragmatic Design for conceptualization of domain knowledge, we also propose a set of conceptual analysis models for analyzing and capturing different domain perspectives as we shall see in section 6.5 later. These conceptual models may themselves be used as patterns for knowledge acquisition. Output: Based on the selected mechanism for knowledge acquisition, a set of domain knowledge descriptions in natural language, a set of questions based on the targeted functionalities are the expected output for this phase. Procedure: Select appropriate design tool, design methodology from current state of the art design methodologies and tools. Illustration: We choose Protégé Ontology Editor as our ontology design and development tool. For the conceptual modeling, we can use any conceptual modeling tool like Rational Rose and MS VISIO. For the design methodology, we choose to follow the O4IS design methodology and USP2 Design, as proposed in this research. For the actual knowledge acquisition, we assume that a natural language description of the domain is our input. A combination of other methods may also be used. 102 5 Ontology for Information Systems Design Methodology

The outputs from all the above steps form the input to the next steps of this design methodology. So far, we have been preparing ourselves for the actual design and development or ‘construction’ phase.

5.2.8 G7: Knowledge analysis - conceptualize the domain ontology

Once the domain knowledge has been captured, the designer needs to choose a mechanism for analyzing and thereafter modeling the implicit and explicit knowledge retrieved. Here, we propose that the designer makes use of our Uniﬁed Se- mantic Procedural Pragmatic Design approach, to methodically analyze and model the semantics (concepts), and then the dynamics (procedures) and the pragmatics (using deontic analysis models, speech act theory, or other linguistic analysis formalisms). The 5Ws approach- who, why, where, when, and what - is also a handy analysis tool. Our proposed USP2 design methodology also builds on some of the fundamental steps introduced by the Noy guidelines, and that by Gruninger and Fox. As we shall see in detail in the following section, we propose a detailed methodology for conceptualizing the domain knowledge from different perspectives:- the semantics; the procedural; and the pragmatic. For doing this, we provide the na¨ıve designer with guidelines to build conceptual models of the domain by identifying the central entities or objects of interest, their roles, and how they relate to each other, viz semantic relationships. Input: Output from all the previous steps discussed so far, knowledge analysis methods and models, our proposed USP2 design methodology. Output: A set of conceptual models following the proposed design methodology. Procedure: The designer has to carry out the knowledge analysis and subsequent representation as conceptual models following our proposed USP2 design,as presented in detail in chapter 6. Illustration: From G7 and G8 phases we follow the USP2 design methodology and at the end of this step we should have identiﬁed the semantic concepts and their semantic relationships. We shall see details of this step when we discuss our USP2 Design in the following chapter. For our running case example, we would have concepts of ‘car’, ‘customer’, ‘rents’ and ‘hires’.

5.2.9 G8: Knowledge representation - implement the domain ontology

In this phase the designer ﬁnally implements the conceptual models as formal ontology. Input: Set of conceptual models designed at the end of previous step, ontology development environment or tool, or ontology tool to translate UML to OWL, or transformation rules for mapping from conceptual models into any desired formal ontology language. 5.2 Introducing the O4IS Design Methodology 103

Output: Formal ontology artifact implemented using chosen ontology editor or equivalent tool. Procedure: Noy & McGuinness (2001) provide a stepwise, easy to follow design methodology for ontology developers, albeit closely adapted to the Protégé ontology editor tool. But the fundamental goals and objectives of ontology design are generic enough to be adopted for other ontology development environments as well. It is particularly useful in capturing the descriptive concepts and their relationships of a domain. The last two phases of this guideline ensures repeatability and also reduces the subjective bias of the ontology designer. Illustration: As stated in the previous step, we shall discuss this step in detail in the following chapter. For our car rental ontology example, we would create an OWL project in Protégé ontology editor, insert all the concepts, their characteristics, relations and axioms. Some plugins support the import of XMI files from UML class diagrams. It is expected that more tool support for automatic translation from conceptual models in to OWL formalism will be available in the future.

5.2.10 G9: Evaluate, assess and verify the domain ontology

In this penultimate step we carry out a key role of evaluating and assessing the designed ontology. Input: The designed ontology, competency questions set up earlier, functional requirements that were to be met, domain experts to verify the ontology. Output: Designed ontology is assessed, evaluated and verified as may be required. Procedure: We choose the competency questions phase as suggested by Gruninger and Fox (1995), for assessing the minimum level of required information to be captured and modeled to support the level of inferencing and targeted application usage. Also, they help in tracking and authenticating the source and interpreted information for verifiability and validation. As mentioned earlier, since our main aim is in domain knowledge representation, we also adopt Davis et al.’s (1993) knowledge representation roles as evaluation criteria to assess if our conceptualized ontology fulfills its purposes. To verify the ontology, we regard the domain experts and the targeted users as the final authority to verify and check if our conceptualized abstraction reflects the reality of the domain in question. Illustration: We choose the competency questions for our car ontology as those listed earlier,like what makes of car are there? What are the different leasing packages offered to a customer? What are the features for a specific model of a car? 104 5 Ontology for Information Systems Design Methodology

5.2.11 G10: Use, maintain and manage the domain ontology

Finally, the designed ontology has to be used, maintained and required modifications made from time to time. Input: We propose to follow parts of METHONTOLOGY for its evolving life cycle, like its more structured goals of planning, modeling, development, documentation and maintenance as it fits closely with the need to be flexible, adaptable, extendible and evolving. METHONTOLOGY follows the software development life cycle closely and emphasize on the need for maintenance, documentation and validation of the ontology. Output: The expected outcome is that we have an evolving ontology that can be used, populated and updated periodically. It should be used by other applications as well. Procedure: It is not enough to have designed and developed the structure and schema for the ontology, just as in the case of a good database design. Information needs to be populated inside the designed ontology as well. Na´ıve users need help and support in making use of the proposed ontology, either as a look up dictionary or as a knowledge base. Our proposed Semantic Analysis Representations (SARs) like the ECA rule ontology(section 6.5.6)and the DAM(section 6.5.4) are useful in this stage as well. The SARs help the IS designers in their ontology creation role as well as the end users to populate the designed ontology with relevant information. We have carried out user-feedback surveys as well to assess the usefulness of our SARs in these capacities. We discuss more on this when we present the specific case studies themselves in section 8.9. Maintenance of the designed ontology requires periodic housekeeping activities on the part of the designer. New concepts may have to be added, redundant ones removed, and existing ones modified. As stated, an ontology is a consensus model, and it has to support flexible evolution. It should also support integration of other existing sources, migration of data and information from older legacy systems and data models and so forth. Illustration: In our case scenario, we visualize that once our car ontology is designed and running, we may have to extend it when a new car model with new features arrives, or when a new car leasing mechanism or offer package is introduced, or when a collaboration with another car rental agency is formed. In the last case, we would need to interoperate with their information system. This arena is a research topic in itself, and we do not delve deeply in to this area,but visualize that our future research shall be guided in this direction. The above mentioned guideline aims to help the IS designer in matching the Information Systems specific design requirements, application functionality to ontology principles and methodologies from philosophy and AI. For steps G6- G8, the 5.3 Multi-tiered Domain Ontology Architecture 105 designer needs to also choose the tools and design environment from the available state of the art. The choice depends on the type of ontology being developed. Some of the common tools available today are Protégé, Chimaera 3. We now move on to presenting some of the other methods, models and architecture proposed in the O4IS design methodology above. We begin with the logical architecture for the domain ontology.

5.3 Multi-tiered Domain Ontology Architecture

A multi-layered architecture for designing the ontology is better than a single mono- lithic structure as has been proposed by Guarino (1998), as summarized in section 3.5. This allows faster development, easier maintenance and modification of the ontology. Also it encourages re-usability by others for different applications. Again this structure offers maximum flexibility in design. Again, as summarized by Wache et al (2001), there are other approaches like the single ontology, multiple local ontology or hybrid ontology design architectures for the physical architectural organization of the proposed ontology. The designer may choose whichever of these three physical architectural models that suits his application requirements. We propose that additionally, we have a logical multiple layer design architecture for capturing the domain ontology in a layered structure. The multi-tiered architecture is the proposed input to the guideline 3: choosing the logical and physical architecture step in our O4IS design methodology as highlighted in the figure in the margin. We recommend a stratified logical architecture for domain ontology design based on Guarino’s architecture called the Multi-tier Domain Ontology architecture. But he recommends a layered ontology architecture only on the basis of ontological content and generalisability. We extend Guarino’s proposal to include a multiple- layered ontological structure within the domain ontology itself. We propose that we further separate the conceptualization of a domain from generic to specific application contexts, moving from the intensional to the extensional level as shown in figure 5.8. At the top most generic ‘meta-level’ we would have concepts like entity, Process, Actor which are applicable across many domains. Thereafter, we have specific domain concepts as specializations of the above-mentioned concepts such as Enterprise, Selling and so on. We further move on to the extensional level, that is, defining the specific characteristics of these real world concepts as we would want them to be. For example, Just-in-Time Trading is a specific individual who is an B2B enterprise system. We would also define the trading policies like customer discount options of Just-in-Time Trading here. As we move from the top-most layer successively towards the lower layers, we move from the generic to specific conceptualization of the targeted domain. We 3 From Stanford University http://www.ksl.stanford.edu/software/chimaera/ 106 5 Ontology for Information Systems Design Methodology

Fig. 5.8. Moving from Generic to Speciﬁc Domain Conceptualization

Fig. 5.9. Example for Multi-Tier Ontology

may adopt a top-down, middle-out or bottom-up approach for conceptualizing the content of these multiple layers. The appropriate approach is to be decided in the next step of the O4IS design methodology, namely guideline 4 - choosing a development approach (section 5.2.5). We may have as many layers as required, but we recommend at least three layers:- the top generic domain ontology, speciﬁc domain ontology and the application or template domain ontology as seen in ﬁgure 5.9. Some of the salient features of these three recommended layers are:

• Generic Domain Ontology: The top most layer is the generic domain ontology, and it could even be generic across domains. We should use any of the existing 5.3 Multi-tiered Domain Ontology Architecture 107

standards or accepted domain-related ontology as the generic domain ontology. For example, for our case scenario of a car-rental agency we could use a generic domain ontology related to Vehicles or Transportation. If the scope of the targeted domain necessitates it, then we could even add a further generic ontology like SUMO 4 or BWW Ontology 5 or Open CYC. • Specific Domain Ontology: The next layer, is a selected group of concepts and terminologies specific to the chosen domain itself. In our case, our car ontology and the related concepts of lease-rental form the specific domain ontologies. Note that we could keep these two as separate domain ontologies or merge them as a specific car-rental ontology. As can be seen from figure 5.9, our car ontology is a specialization of the generic vehicle ontology, the lease-rental ontology is a specialization of the generic enterprise ontology. In this specific domain ontology, we still do not add the application specific or the individual case information, like the business policies of Quick Service Car rental agency, or the registration numbers of the cars owned by Quick Service Car rental agency. The idea is to be a specialization of generic concepts, but should still be reusable across other similar contexts. The car ontology should be plugable with other similar car rental applications, not only Peter’s car rental application. • Application/Template Domain Ontology: The next layer will be more focused to a particular local interpretation of the domain, and should be more application oriented as well. Still specific implementation details would not be included here. However, the business policies of Peter’s car rental agency would be modeled here. This is the actual ontology which would be ‘connected’ and used in a web- based application where Peter’s customers can browse, reserve, order cars for hiring on the internet.

5.3.1 Advantages of the Multi-tier Domain Ontology Architecture

The multi-tier architecture is envisioned to provide the following advantages:

1 Portability: A structured model is easy to port, and plug and play with other Information Systems applications. For example, another car dealer could take only our car ontology and plug it with his existing vehicle ontology. 2 Reusability: By developing different levels of abstraction in the domain ontology, we enhance reusability. Speciﬁc applications having speciﬁc needs and specializations will be restricted to the lower most ‘template’ or application ontology. As we move up, towards the generic domain ontology, we increase the level of abstraction, and hence increase reusability. A generic car ontology can be used by another car dealer.

4 IEEE’s Suggested Upper Merged Ontology 5 Bunge Wand Weber 108 5 Ontology for Information Systems Design Methodology

3 Easy to modify, update, de-bug and maintain: A modular design and development is easy to modify and maintain as has been seen in the object oriented design and development paradigm or the Model Driven Architecture. 4 Understandability: Since, we are promoting the use of conceptual models as the first phase of the domain conceptualization, it goes without saying that a logical stratification, reduces the complexity of such models. Thereby, making it easy to read and decipher by humans. 5 Maximum flexibility: A layered structure allows flexible extensibility both in the horizontal as well as the vertical directions. We can add more generic concepts like time, space as defined in foundational ontologies or even more specific templates like for contractual forms and applications. We can extend horizontally, by adding other related ontologies like say a travel ontology which can make use of local car rental agencies.

5.4 Dual Conceptual Representation

As stated earlier, there are many different levels of conceptual representation of ontologies ranging from informal textual representations to complex first order logic formalisms. The choice for the suitable form of representation depends mostly on the targeted users and the purpose for which the ontology is being developed. As recommended in guideline 5 (section 5.2.6), we propose a dual representation of domain concepts for the use in Information Systems as follows: - Semi Formal Conceptual Model Representation: In the first step, we recommend that we should capture and represent the domain knowledge as reusable conceptual models. UML notation is one possible representation language for modeling such conceptual models. We shall discuss more about UML and its role as a conceptual modeling and ontology representation language in the following section 5.4.1. Formal OWL Representations: We recommend the subsequent transformation of the conceptual models into machine readable formalisms like OWL, KIF or any other logic language. We agree that it may seem unnecessary or even extra work to first capture and model the domain knowledge as conceptual models, and thereafter to redevelop or implement as formal ontology. It may sound simpler to follow existing design methodologies and straightaway implement the formal ontology. But, we would like to reflect back to the key issues addressed in section 1.4, namely:

• - The use of ontology in Information Systems has to be promoted and made easy. • We need to give explicit guidance to the IS designer in the design and use of afore-mentioned domain ontologies. 5.4 Dual Conceptual Representation 109

• Information Systems are often reused and should facilitate easy extensibility, interoperability with other Information Systems.

Given the above objectives, we hold the view that:

• Conceptual models are graphical and easy to understand and interpret amongst the human IS designers. • Most IS designers are familiar with entity relationship models and/or object- oriented modeling, hence the slight shift towards ontological conceptualization as proposed by our USP2 Design, is much easier to accomplish. • Having captured domain knowledge as conceptual models, it is feasible to transform the same into different ‘implementation’ representations like OWL, KIF or FOL as may be required by the specific Information Systems application. Hence, reusability is enhanced. • Ontology based interoperability of Information Systems is one of today’s key areas where ontologies are proposed to be used. In such contexts as well, an intermediary conceptual model facilitates the interpretation and modification for interoperability. • Furthermore, the transformation from UML class diagram (conceptual models) to formal ontology (OWL) has been the subject of discussion in works of Crane- field (2001), Baclawski, Kokar, Kogut, Hart, Smith, Holmes, Letkowski & Aron- son (2001), and Kabilan & Johannesson (2004). Also, we would like to point out that current OMG standardization efforts like the Ontology Definition Metamodel (ODM) supports the transformation of these conceptual models into formal language.

We discuss more on the specific suitability of UML as conceptual modeling language in the following section 5.4.1. As we shall see in our case studies, if the targeted application does not warrant a need for formal ontology, then our conceptual models are sufficient as semi-formal ontologies. If our targeted application calls for reasoning and other logical explanations, then, of course we transform our conceptual models into formal ontology representations. In most cases, it should be feasible to have at least a semi-automatic transformation from the conceptual models into formal ontology. Another advantage is that it is possible for us to translate the same conceptual model into different formal ontology languages as well. And just as Sowa suggests, we propose that conceptual models, built using our perspective-based design, will be able to include the expressive power of natural language (lexical structures) in precise, unambiguous, and easy to understand conceptual models. We may also utilize other lexical or logical analysis methods to capture other aspects and pragmatics as well. The idea would then be to first build or reuse if existing, other conceptual models, meta-models or ontologies as the ‘se- 110 5 Ontology for Information Systems Design Methodology mantic building blocks’. Natural language, though expressive is not computable (i.e, machine understandable). Conceptual models are a choice in between, they have high degrees of expressivity and also support computability indirectly, since they can be translated into computable ontology representations. In the following section we look at one such conceptual modeling language, UML and its suitability for the ontological conceptualization.

5.4.1 UML for Conceptual Modeling and Ontology Representation

We have discussed the advantages and suitability of UML as a conceptual modeling language in a former publication (Kabilan & Johannesson 2004). UML has a large number of users in the Information Systems domain due to its graphical, easy to understand features. In contrast the domain of ontology experts is quite small and it is not practical to expect the vast majority of non-ontology experts to learn new ontology languages in order to translate or model new knowledge bases. UML conceptual models are not only easy to understand and reuse but they also support easy interoperability and/or integration with other ontologies. Two of the main issues of knowledge representation are interoperability and reusability. The key to resolve both issues is ‘semantics’ that is modeling and capturing the meanings rather than representing knowledge in syntax and speciﬁcations. We propose the use of UML class diagrams for representing the conceptual models. We refer to UML class diagrams as UML conceptual models throughout this paper. The advantages of UML as an ontology modeling language have been proposed by Craneﬁeld & Purvis (1999) and Baclawski et al (2001) as:

• It has a growing user audience in the software domain for object-modeling languages and other information systems design. • The graphical notation for UML is easy to comprehend and use and is suitable for human-to-human knowledge transfer. It has been designed for use and communication between humans for software design purposes. • UML can be extended to suit the need of ontology deﬁnitions. • Object Constraint Language allows expression of rules and constraints. Crane- ﬁeld (2001) has proposed mappings to transform UML ontology models in to RDF and to generate Java classes from UML using XSLT 6.

UML by itself is weak on the descriptive semantics part. It uses as many as twelve different diagrams to capture different aspects of semantics. Other disadvantages or weakness of UML have been investigated by other researches like for example the use of referentially redundant modeling constructs has been discussed by Opdahl &

6 http://www.w3.org/TR/xslt 5.4 Dual Conceptual Representation 111

Henderson-Sellers (2005). The most commonly used notation is that of UML class diagrams for modeling the static descriptive concepts (terminologies) of an ontology. Additional constraints maybe captured through the use of OCL(Object Constraint Language). As we see with the ODM (Ontology Deﬁnition Metamodel) (2006) efforts, the use of metamodels has been introduced to increase the semantic capability of UML class diagrams. As yet, the dynamic and organizational aspects captured by UML activity diagrams, state charts,and synchronization diagrams, have not been utilized or mapped to equivalent ontological transformations.

R To overcome this issue, we have made use of UML class diagram (conceptual model) as the representation template to capture the other aspects as well. We have proposed a set of conceptual models for speciﬁc behavioral, procedural or pragmatic aspects of domain knowledge, as we shall see in section 6.5. By this, we are able to capture the dynamic, procedural aspects in the UML class diagram notation to a certain extent.

Baclawski (2001) has compared the advantages and disadvantages of UML as an ontology modeling language over other ontology language speciﬁcations like RDFS 7, and DAML 8. The UML conceptual models may also form the base for rigidly formal ontology deﬁnition formats like KIF(Knowledge Interchange Format). With that we come to the end of this chapter. We shall continue our discussion on the suitability of UML as a conceptual modeling language throughout this thesis. We now present our conceptualization design methodology for capturing the semantics, procedural and pragmatics of a domain in the next chapter.

7 Resource Description Framework Schema. http://www.w3.org/TR/rdf-schema/ 8 Darpa Agent Markup Language, the original language which has been adopted in the OWL speciﬁcation. http://www.daml.org/

O 6

Uniﬁed Semantic Procedural Pragmatic Design

Most enterprise and business process ontologies model static concepts, i.e. endurants. Dynamic concepts, i.e. perdurants, such as change or process, need to be conceptualized in a way to enable modeling of automated business processes. En- terprise Ontology project (Uschold et al. 1995) and Guarino’s approach (1998) have addressed the issue of capturing the procedural aspects of the domain. They advocate a separate activity ontology (Enterprise Ontology) or task ontology (Guarino’s ontology architecture). Guarino’s proposal of task ontology or the MIT process handbook ontology 1, or the Activity ontology of the TOVE ontology suite, each manages to represent the concepts behind these procedural domain knowledge. However, the design methodologies themselves are not explicit on how a designer should analyze a domain and how the IS designer should choose which particular aspect of a task is to be a concept, which business constraint is to be modeled as an axiom, what is to be expressed a rule, what is to be a concept characteristic and so on. As discussed earlier, every domain has many perspectives including the semantics, dynamic procedural aspects as well as intended meaning or pragmatics. We need to conceptualize all these as descriptive ontology. We motivate the need for a coherent semantic, procedural and pragmatic analysis by considering an illustrative example, consider a business scenario: In a fast food burger restaurant, it is customary that the customer views the menu, makes his choice, goes and places his order, pays for it, receives his food. Identifying the main domain concepts in this business scenario is simple: customer, fast food restaurant, salesperson, food, money, order, menu. But we also see that there are more business activity-oriented concepts like, the customer places order, salesperson issues bill, customer pays bill, salesperson delivers food, customer eats food. Each of these ‘actions’ may consist of several actions in themselves. That is,

1 The MIT Process Handbook is a project to develop extensive library of business process concepts and currently defines over 5000 business activities. It can be browsed online at http://process.mit.edu/Default.asp 114 6 Unified Semantic Procedural Pragmatic Design they are what we know as business processes. For example, delivering food could include prepare food, package the food, add cutlery, add condiments. The MIT process handbook ontology describes a series of such common business activities and processes like make, sell, and produce, etc. In fact, they follow the SCOR models 2. But, how do we model the other aspects like that the customer places order first and then pays and then gets food so on ? This ‘sequencing’ of events is normally represented using notations like UML activity diagram, Event Process Chain diagrams, petrinets, Business Process Modeling Notation or any other such business process or workflow modeling language (see summary in section 4.6). It is also possible to capture the constraints, like that The customer shall be served his food within 15 minutes or else the restaurant returns the money. Or say, that the customer can pay by credit card only if the amount to be paid is more than 10 euros. The issue at hand is,

How do we express the semantic, procedural and pragmatic aspects de- scriptively in an ontology?

R Our answer to the above question is the Uniﬁed Semantic Procedural Prag- matic Design that is a methodology which instructs Information Systems designers to visualize, conceptualize and represent the domain knowledge from the above mentioned perspectives. The USP2 Design also puts forward and makes use of a set of Semantic Analysis Representations that are conceptual analysis patterns for the Information Systems designer to use in the analysis of the different domain aspects and to model them in the design phase of the domain ontology. The same may also be used as analysis patterns and tools by the end user while populating or using the designed ontology. The USP2 Design methodology may be used by any IS designer on its own or as a sub methodology included in the overall O4IS design methodology as is the case in this research. The USP2 Design does make use of the design decisions made in the O4IS design methodology from G1 to G5. The USP2 Design covers the G6 to G8 steps in the O4IS design methodology, namely that of knowledge analysis, conceptualization and representation. As such, this is one of the key contributions of this research. Figure 6.1 illustrates the structure for this chapter. We begin with an overview of the USP2 design in section 6.2. Then, we summarize the related theory for the USP2 Design in section 6.3 and section 6.4. After having introduced the reader to the background, we present our Semantic Analysis Representations (SARs) for semantic analysis of different perspectives. These patterns and models are used as inputs for the analysis to be done in the USP2 Design. Finally we present each of the 2 The Supply-Chain Operations Reference-model (SCOR) is a process reference model that has been developed and endorsed by the Supply-Chain Council as the cross-industry standard diagnostic tool for supply-chain management.http://www.supply-chain.org 6.1 Semantics, Procedures and Pragmatics 115 semantic, procedural and pragmatic concept view along with detailed guidelines for conceptualizing each of them in section 6.6, section 6.7 and section 6.8 respectively.

Fig. 6.1. Disposition of Chapter: USP2 Design

6.1 Semantics, Procedures and Pragmatics

Analyzing and representing behavior and procedures in Information Systems is not uncommon. Procedures, behaviors and pragmatics have been addressed in Infor- mation Systems using different data modeling (Data ﬂow diagrams, event process chains, UML activity diagrams) or process modeling languages, as also brieﬂy reviewed in section 4.6. Additionally, Weirenga and Meyer (1993) have provided a concise survey and review of deontic logic based applications in computer science. Grosof (1999) in his RuleML work points out that the traditional method of modeling business is a procedural where we capture the rules and policies as data level validations and pre-conditions and post conditions for user actions and triggers. He advocates a change in rationale for conceptualizing the behavioral and procedural aspects as a logical axiom and rule not on data level but on the semantic object level. Colomb (2002) proposes the use of conceptual models to represent the endurants, and suggests that behavior and procedural aspects (what we call as perdurants in ontology modeling) are captured using use case scenarios, collaboration diagrams, activity diagrams and state-chart diagrams in UML conceptual modeling. However, this design/ modeling approach:

• Does not provide a coherent visualization of the entire domain of interest that is, each of the diagrams provides a partial information and we need to go through all the diagrams to get the whole picture. It does not support easy communicability, sharing between human users. • Does not help in making implicit information explicit, like the causal reasons or effects behind the occurrence of the perdurants, or factors producing effects in the current domain of interest but whose origin may itself be outside the current scope of the domain. For example, how would we represent that the customer orders food because he is hungry? How should we model that food being served 116 6 Uniﬁed Semantic Procedural Pragmatic Design

cold is ‘unsatisfactory’ to the customer? What about the implicit understanding that the food should have been prepared in hygienic environment? • As yet there is little or no research on mapping/translating other UML diagrams except class diagrams in to machine readable OWL.

Some possible alternatives to this issue of capturing, analyzing and representing the procedural and pragmatic aspects of the domain could be:

1 The W3C recommendation would be to model some of the business constraints as rules using the Semantic Web Rule Language (SWRL). 2 We could also use the new OMG proposal for Semantic Business Vocabulary and Rule Ontology (SBVR)(OMG & Group 2006) 3. 3 The OWL-S Process Ontology 4 is another promising candidate for analyzing and representing behavior as ontology concepts. 4 Grosof et al.’s (1999) work on RuleML, his continuing work on business contracts in SweetDeal (Grosof & Poon 2003). 5 Related research in the field of deontic logic and other logical description of rules, procedures, including those analyzing and capturing the specifics of business obligations. We review some of them in the first case study related with the business contract domain, in section 7.2.

We derive inspiration from the above mentioned related research, speciﬁcally the OWL-S Process Ontology. To use any of their proposed techniques, languages, we believe, that a methodology is needed which will help the IS designer in choosing which of these techniques is best suited and which aspects of the domain can be best modeled using them. R In this research, we argue that an ontological modeling of a domain should not only list the static concepts (endurants) and their relationships, but also the perdurants as a basis for conceptual modeling of the domain. To capture and represent the domain knowledge,we propose a structured, perspective based approach, Uniﬁed Semantic Procedural Pragmatic (USP2) Design. The USP2 Design recommends an IS designer to analyze the domain from different perspectives for extracting the semantics; the procedural behaviors, and implicit pragmatics. There- after the analyzed information is expressed them as explicit conceptual models.

3 This specification defines the vocabulary and rules for documenting the semantics of business vocabulary, business facts, and business rules; as well as an XMI schema for the interchange of business vocabularies and business rules among organizations and between software tools. 4 W3C recommended Web Ontology Language for Services. Consists of a set of ontologies including Service Ontology, Process Ontology, Profile Ontology, Grounding Ontology, Logical Expression Constructs, List Constructs, Actor Ontology and Profile additional parameters. Detailed description may be referred to at http://www.w3.org/Submission/2004/07/ 6.2 Introducing the USP2 Design 117

6.2 Introducing the USP2 Design

We propose that we analyze the same domain from different perspectives to get the semantic concepts(vocabulary), the procedural dynamics(behavior, rules, constraints), and the pragmatics (how, why, reason, cause-effect) of the domain. For each of the perspectives, we discuss the available approaches and techniques for carrying out the analysis. We also present a set of conceptual models (Semantic Analysis Representations, introduced in section 6.5) that may be used as patterns for aiding the analysis process. For example, we propose the ECA Rule Ontology as a pattern for analyzing the business operative rules using the Event Condition Action paradigm. Most of the domain knowledge is usually available as natural language descriptions. The goals of natural language understanding and semantic conceptualizations of domain knowledge representations, as investigated by Sukkarieh (2001), are similar to those of ontology design goals and objectives in Information Systems as mentioned earlier. Yet, there exists a gap in design methodology how this extraction of explicit and implicit knowledge from natural language can be represented and modeled as conceptual models. Conceptual models as knowledge representation models are generally graphical and easy to understand. So for this research, we restrict ourselves to the context of natural language (English language) interpretation to knowledge representation as conceptual models.

Fig. 6.2. Uniﬁed Semantic Procedural Pragmatic Perspectives 118 6 Uniﬁed Semantic Procedural Pragmatic Design

We propose that a designer should ‘view’ the natural language descriptions of the domain under consideration from different perspectives (objectives) and model each of them separately as a conceptual model. Finally, these can be combined to form a single formal (machine readable) knowledge representations. The proposed views are, as illustrated in ﬁgure 6.3:

• The Semantic Concept View describes the knowledge (declarative knowledge) about the world and its fact repository. In the example illustrated in figure 6.2, we have a customer ordering a burger meal at a fast food restaurant. Examples of semantic concepts involved in this scenario are burger, money, pay, and order. • The Procedural Concept View describes the knowledge (procedural knowledge) about the emotional states, intentions, plans and rules. In figure 6.2, illustrative examples of procedures could be the ordering of food, the cooking of the burger, food being delivered and the customer paying for food and so on. As we see, they utilize the semantic concepts. • The Pragmatic Concept View describes the knowledge about the implied intentions, modalities of obligations and pragmatics of action. Again in figure 6.2 we see that there are inherent business policies at work, say for example, customer satisfaction is guaranteed and so if the food is not satisfactory, the restaurant promises to refund the money.

R The USP2 Design endeavors to aid in the analysis of natural language and model them as reusable knowledge representations (conceptual models). As discussed in chapter 4 earlier, these form analysis patterns in themselves, as they guide a designer in analyzing a given domain from a certain perspective. In addition we also propose a set of patterns for the analysis of relationships between concepts called Semantic Analysis Relationships (SARs) that are conceptual modeling patterns following the suggestion from Cabot & Raventos (2004) as discussed earlier in section 4.5.1. Currently we propose the following categories for the SARs (to be discussed in section 6.5):

i Structural relationships. ii Functional relationships. iii Temporal relationships. iv Prescriptive relationships v Deontic relationships.

R The aim of this perspective based design approach is to help the non- ontology expert, information system designer to methodically review the domain under consideration to extract, analyze and represent the concepts and their meaning (semantics), their intentions (pragmatics) and plan of action (procedural knowledge). Just as Sowa (1999) suggests, we propose that conceptual models (built using 6.3 Verb Phrase Ontology 119 our perspective based design) shall be able to include the expressive power of natural language (lexical structures) in precise, unambiguous, and easy to understand conceptualizations. The ﬁnal set of conceptual models obtained as a result of the USP2 Design need not be separate individual perspectives, but a composite view, where the analysis of each perspective is added on to the concepts from the other views. Figure 6.3 illustrates the idea more clearly. As seen in the Venn diagram the semantic concept view forms the universal set of domain vocabulary, where the Pro- cedural and Pragmatic concept views are subsets describing speciﬁc aspects of the domain.

Fig. 6.3. Semantics-Procedures-Pragmatics Domain

But before we present the USP2 Design, we summarize some related work that has been adopted in our research, namely Storey & Purao’s (2004) the verb phrase ontology (section 6.3) and Vanderveken & MacQueen’s (1990) semantic analysis of performative verbs (section 6.4).

6.3 Verb Phrase Ontology

Veda Storey and Sandeep Purao have proposed a verb phrase ontology for classifying the semantic relationships that can exist between entities in the real world. Their objective is to: Propose an ontology for understanding the semantics of relationship verb phrases by mapping verb phrases to various categories that capture different interpretations. Their verb phrase ontology has three classification levels as shown in figure 6.4, namely: 120 6 Unified Semantic Procedural Pragmatic Design

Fig. 6.4. Semantic Relationships: Classiﬁcation Levels

• Fundamental categories: These represent the natural division that can be seen in the real world. There are three basic types of fundamental categories: status, change of status and interaction. We summarize these separately below in section. • Local (internal) categories: This category takes into account the specific nature of the entities surrounding the verb phrase. Storey and Purao classify entities in to three possible types: actor, action and artifact. Actors are entities capable of performing actions. Action represent the performance of the acts specified. Artifacts are inanimate objects that are not capable of independent action. In the local context, the primitives from the fundamental categories are constrained into groups of valid combinations. • Global(external) categories: The third level is used to capture the external domain in the context of which the verb phrase is used. For example, let us consider the verb opens in the context of a room. Student opens door has a different meaning than in the context of a banking domain, where Customer opens account. In the first example, the domain is mapped to the primitive manipulates. In the second example, the domain is mapped to is-owner-of.

They begin by identifying some fundamental categories for relationships: status; change in states; and interaction. 6.3 Verb Phrase Ontology 121

Fig. 6.5. Status primitives from Verb Phrase Ontology

• Status: They define Status to be the orientation of one entity towards another entity, e.g. A B. As seen in figure 6.5, some of the primitives they have put together from their literature survey and extended include structural, influential, temporal, spatial and attitudinal. • Change of status: change of one entity with respect to another: A B. (this is particularly relevant for us since we wish to identify dynamic or changing states and relationships. • Interaction: describes the communication between entities that does not result in a change of state, like in the case of messaging,A B. Detailed classification can be seen in figure 6.6.

Status describes an enduring relationship between two entities which does not undergo any change in time. Change of status describe transient relationships where the relationship between two entities undergoes a change into another kind of relationship. Interactions are used to describe notable effects or results of some relationship being changed or processed. R We agree with the classification levels as proposed by Storey and Purao. We adapt their verb ontology by (i) re-grouping the primitives under a different perspectives, and (ii) specifying the local context for their fundamental categories. We hold the view that the local context that we have specified is still generic across different domains, some of them being action-oriented and some entity- 122 6 Unified Semantic Procedural Pragmatic Design

Fig. 6.6. Interaction primitives from Verb Phrase Ontology

oriented. We have regrouped the fundamental categories with respect to our three perspectives: semantics, procedures and pragmatics. We use these as a set of analysis patterns for the conceptual modeling of the domain. We shall discuss more about Storey & Purao’s (2004) work when we present our guidelines for the USP2 Design. Storey has mainly used this semantic relationships and ontological foundations to propose an improved database design. We make use for her ideas to facilitate the semantic analysis for ontology modeling.

6.4 Performative Verb Ontology

As we shall see later, performative verbs are said to belong to ﬁve fundamental categories, namely, assertives, commisives, directives, declaratives and expressives. Vanderveken has carried out a semantic analysis of about 200 odd English performative verbs, and we have based our performative verb ontology primarily on his work. The basic semantic pattern is of the type Actor Actor, The Entity 1 actor is termed as ‘Speaker’ or ‘Performer’,and the entity2 actor is termed as ‘Hearer’ or the ‘Target’ in the context of the pragmatic analysis that we are currently doing. Some illustrative examples are listed in table 6.1. As we shall discuss in section 6.5.4, the speech act theory analyzes the intentions, beliefs of the actors involved in any social communication. This provides us the contextual domain which is to be analyzed and represented in the pragmatic concept view. As stated earlier, the Pragmatic Concept View and the analysis for the contextual interpretations is necessary, only if the targeted application for the proposed ontology demands it. 6.4 Performative Verb Ontology 123

Table 6.1. Examples of Performative Verbs Performative Verb Type Example Assertive The seller notiﬁes the buyer that his shipment is ready. Commissive The student promised to complete his as- signments by the end of the week. Directive The government has asked all citizens to ﬁle their income tax returns by May. Declarative The judge granted pardon to the defen- dant. Expressive Peter congratulated John on his new chairmanship.

In this section, we now introduce the Performative Verb Ontology as a pattern or analysis tool for the Information Systems designer to use for extracting these pragmatic aspects from the domain of interest. The fundamentals of speech acts was laid by Austin (1962) who proposed that semantics of uttered words was more than the literary meaning of the words themselves. A constative or locutionary act involves the utterance’s proposition or its propositional content. However, one has to go beyond the propositional content of the utterance when one wishes to see the language -action perspective that is performatively. A term used in relation to the performative, is the illocutionary act, where one uses an utterance to perform a speech act. An illocutionary act also has an effect on the hearer. Austin calls this effect the perlocutionary act.The intended illocutionary force of the imperative ‘Send me 3 dozen bananas by Friday’, for example, is implicit, as what the speaker has in mind by saying it is not specifically indicated. The implicit nature of the contract clause given above may be interpreted based on the paralinguistic or kinesic cues given by the speaker, and on the power or status relationship between the speaker and hearer, as either a command or a request. In order for the speaker to make the illocutionary force explicit, he or she has to indicate the speech act involved by adding the performative verb before the clause. Our work adopts and extends Vanderveken & MacQueen’s (1990) work on the semantic analysis of English performative verbs. Vanderveken sets out to understand the correspondence and distinctions of the speech act verbs with their performative uses, their illocutionary force and the directed use of these speech acts. The basic model followed for the speech act verb is of the form Speaker Hearer. Vanderveken aims to understand the paradigmatic central illocutionary meaning of the speech act verbs, henceforth referred to as Performative Verbs in this thesis. He has put forward an in-depth study, and semantic (taxonomy) classification of over 200 English performative verbs. 124 6 Unified Semantic Procedural Pragmatic Design

John Searle (1969) in his taxonomy of speech acts proposes a set of illocutionary points and Vanderveken has carried out his semantic analysis of English performative verbs under the same classiﬁcation:

• Assertives: Represent how things are in the world. Examples from Vanderveken’s analysis: Assert, Reassert, Negate, Deny, Correct, Claim, Declare, Hypothesize, Criticize, Complain, Notify, Inform, Predict. • Commissives: Commit oneself to carrying out a future action in the world.Examples from Vanderveken’s analysis: Commit, Pledge, Undertake, Engage, Promise, Threaten, Vow, Assure, Reject, Refuse, Offer, Counter-Offer, Dedicate. • Declaratives: Perform an action in the world by saying that the one is doing it. Examples from Vanderveken’s analysis: Declare, Renounce, Grant, Sentence, Cancel, Convene, Sanction, Disapprove, Repudiate, Licence, Vote, Nominate, Sustain, Install, Open. • Directives: Try and get someone else to act(perform) in the world. Examples from Vanderveken’s analysis: Direct, Request, Ask, Question, Inquire, Interro- gate, Discourage, Appeal, Petition, Claim, Order, Prescribe, Enjoin, Endure, Au- thorize, Propose, Warn, Allow, Permit, Commission, Command, Advise, Suggest. • Expressives: Express attitudes concerning supposedly existing facts in the world. Examples from Vanderveken’s analysis: Approve, Compliment, Praise, Laud, Complain, Boast, Rejoice, Cheer, Blame, Congratulate, Thank, Condole.

In his work, Vanderveken has analyzed around 70 assertives, 32 commissives, 56 directives, 85 declaratives and 28 expressives. Of course, some performative verbs belong to more than one fundamental classification depending upon its performative use. We have compiled his work as an ontology using Prot’egé ontology editor. This facilitates easy reuse for the designer who can to use this as a look up or reference model. Further more, in addition to recreating Vanderveken’s proposed classification, we have semantically enriched the Performative Verb Ontology with WORDNET as a linguistic resource. Therefore, the performative verbs have been defined with the English word sense and at the same time, we have also semantically enriched the Performative Verb Ontology by mapping to other synonym verbs,which were not initially included in Vanderveken’s work. Figure 6.7 depicts the semantic tree extract for part of our implementation of the Performative Verb Ontology in Protégé. Fig. 6.7. Performative Verb Ontology 126 6 Unified Semantic Procedural Pragmatic Design

6.5 Semantic Analysis Representations: Discovering Semantic Relationships

In this section, we now present the set of semantic analysis patterns for relationship analysis that aim to make explicit domain knowledge. These are visualized as sets of conceptual models or semantic patterns which should enable an information system designer in making consistent design and modeling choices. The aim is that by using such conceptual modeling patterns(as proposed by Cabot and discussed in section 4.5.1) we have the following advantages: (a) It becomes easier for an IS designer to design and conceptualize the domain. (b) it reduces the subjective bias that each designer may have, thereby producing consistent conceptualizations. R Our proposed conceptual modeling patterns that we collectively call the Semantic Analysis Representations, primarily aim at classifying, discovering and establishing the different types of relationships, interactions, dependencies that exist between the concepts (entities) of a given domain of interest. Some of our conceptual analysis models are represented using tabular text, some as UML conceptual models, and some as OWL ontology. At present, we have proposed the following set of SARs:

• Structural Relationships: Relationships between entities that may exist between actors, roles or artifacts (following Storey’s deﬁnition) that deﬁne the taxonomi- cal, or physical or constructive relationship. • Functional Relationships: Relationships that semantically describe the functional associations like cause-effect relationships. • Temporal Relationships: Relationships between actions that describe the temporal logical sequence for execution or enactment. • Deontic Relationships: Relationships that describe social acts and the intentions of the actors in a social world. It also included the speech act based deontic relationships that are implicit in such social behavior context. • Prescriptive Relationships: Relationships that are dynamic, behavior oriented and often are normative declarations. Also includes constructs for rules.

Of the above, the first two are based on Storey and Purao’s work. The third extends their basic temporal relationships with linear temporal logic constructs, the fourth is our proposal to capture the domain deontic using Deontic Analysis Model and the fifth is our proposal to capture prescriptive behavior using Event Condition Action logic. The first three semantic relationships mentioned above are formulated as tabular patterns for the Information Systems designer to look-up and use as appropriate in the described Semantic Concept View or Procedural Concept View as we shall see later. The last two, namely, the deontic relationship and the prescriptive 6.5 Semantic Analysis Representations: Discovering Semantic Relationships 127 relationship are visualized as UML conceptual models and in addition to being helpful analysis models, they can also be used as knowledge storage formalisms, as we shall see later in our case studies.

6.5.1 Structural Relationships

R In table 6.2 we propose for the context of ontology modeling, the valid combinations of entities to be related by the status primitives. The general pattern is where entity1 and entity2 may be actors, objects or attributes, as shown in table6.2:

Table 6.2. Structural Relationship Patterns No. Entity1 Entity2 Valid Status Primitives Example 1 Object Object is-part-of Car < has > Body 2 Object Attribute is-part-of Car < has > Color 3 Object Object is-instance-of Video Tape < is-a-copy-of > Movie 4 Attribute Attribute is-instance-of Red < is-instance-of > Color 5 Actor Actor is-member-of Player < is-member-of > Ice Hockey Team 6 Object Object is-version-of Draft < is-version-of > Thesis

6.5.2 Functional Relationships

R We propose a set of valid functional relationship patterns based on Storey and Purao’s work as shown in table6.3. Functional relationships are of the generic pattern Actor/Object–verb– Actor/Object/Action. R We have restricted the allowable combinations for the entities to be related by the primitives of Interaction, Status fundamental primitives. Of the valid set of combinations, we have a set of valid primitives for associating action –verb– action functionally as seen in table 6.4. These are useful to identify the procedural sequencing of actions based not on their temporal order but on the logical order and preconditions. 128 6 Uniﬁed Semantic Procedural Pragmatic Design

Table 6.3. Functional Relationship Patterns No. Entity1 Entity2 Valid Primitives Example Interaction Category Sub Category: Not Causing Change 1 Actor Object View Status Analyst Requirements 2 Actor Object Select Customer Car 3 Actor Actor Communicate Buyer Seller 4 Object Object Communicate Modem < negotiates-with> Telephone Line 5 Actor Object Perform Buyer Goods Sub Category: Performance 6 Actor Action Perform Buyer< does> Buying 7 Actor Object Operates Pilot <ﬂies> Aircraft 8 Actor Actor Serve Salesperson < serves > Customer Sub Category:Causing Change 9 Actor Object Manipulate Examiner Exams 10 Actor Object Transmit Bank Money 11 Actor Object Receive Buyer Shipment Status Category Subcategory: Temporal 12 Action Action Follow/Precede Car Rental Car Booking 13 Action Action Requires Construction Approval Subcategory: Spatial 14 Object Object is-next-to Finland < is-neighbor-to > Sweden

Table 6.4. Action-Action Functional Relationships Action1- Explanation Relationship- Action2 is a sub action of action 2 is carried out as a sub task of action 1 in order that action 1 is to be done in order that action 2 may be performed is an alternative to Action1 may substitute action2 in response that action 1 is carried out in response to action 2 is a prerequisite for action1 must be completed as planned before the com- mencement of action 2 is a template for action 1 is an example for action2 to conform to. is the cause for action 1 is the cause for action 2 uses as a reference Constitutes relationships between plans, orders or requests 6.5 Semantic Analysis Representations: Discovering Semantic Relationships 129

6.5.3 Temporal Relationships

Based on the linear temporal logic theory, we have a set of possible semantic patterns for associating any two actions as shown in the figure 6.8. As we can see we have two sets, one for an closed time intervals and another for open time interval (figure 6.9). If A and B are two events or actions, then for closed time intervals, we can have the following possible temporal relationships as in figure 6.8. If A and B are two events or actions, then for open time intervals as in figure 6.9. 130 6 Unified Semantic Procedural Pragmatic Design

(a) A starts and ends after B (b) A ends after B

(e) A starts and ends before (f) B starts and ends before A B

(g) A starts after B (h) A starts after B starts and starts and ends when B ends when B ends ends

(i) A starts when B starts (j) A starts when B and ends after B ends starts and ends before B ends

(k) A starts before B starts and (l) A starts after B starts and ends after B ends ends before B ends

(m) A starts when (n) A starts before B starts B starts and ends and ends before B ends when B ends

Fig. 6.8. Temporal Relationships for Closed Intervals 6.5 Semantic Analysis Representations: Discovering Semantic Relationships 131

(a) A starts before B starts (no (b) A starts after B starts (no statement about endings) statement about endings)

(c) A starts before B ends (no (d) A ends after B starts (no state- statement about A ending or B ment about A starting or B ending) starting)

(e) A ends before B ends (no state- (f) A ends after B ends ment about starting) (no statement about starting)

(g) A ends before B starts (no (h) A starts after B ends (nothing about statement about A starting or B A ending or B starting) ending)

Fig. 6.9. Temporal Relationships for Open Intervals

6.5.4 Deontic Analysis Model: Deontic Relationships

Jones and Sergot (1992b) have proposed that at the appropriate level of abstractions – law, computer systems and other organizational structure may be viewed as instances of normative systems. They define ‘norms’ as prescriptive descriptions of how agents ought to behave and specify their permitted behavior and rights. They go on to argue that deontic logic needs to be considered whenever it is necessary to make explicit, and to reason about, the distinction between ideality and actuality. Since deontic logic has its origin in the study of law and its ethics, there have been a number of researches carried out in the field of applying deontic logic to the legal knowledge representation, as has been surveyed by Sergot (1990). Jones and Sergot (1992a) have also proposed a methodology for legal representation using deontic logic. We do not delve deeply into the formal deontic logic analysis or formalizations as that are not mandatory for building conceptual models, since the targeted purpose is that of an Information Systems application where a formal deontic logic expression may not be needed. Also, IS designers, who are the targeted users for the proposed design methodology and Deontic Analysis Model, are not 132 6 Unified Semantic Procedural Pragmatic Design required to be formal logicians. So, we restrict ourselves to the deontic analysis of natural language prescriptions with the objective of knowledge representation as conceptual models. The root of our DAM is the Act concept, since we are interested in the world of human actions and behavior. Actions are carried out due to some purpose, in some context by some actor (in our case humans, could be individuals or enterprises). Act could be carried out by an actor for himself, as a Solitary Act or as in most cases, as a Social Act. Social Acts are those actions carried out by actors as a result of interaction between different actors for some given purpose. Each Social Act aims to create a Deontic Proposition which is the linguistic expressed communication or statement which proposes the nature, mode, intentionality to fulfill of the act. A Deontic Proposition has a type of assertion, Deontic Assertion, which indicates the nature of the proposition being made. The exhaustive lists of basic De- ontic Assertions are Obligation, Permission, Prohibition and Rights. Other assertions like request, desire, and guarantee may all be subsumed in to these basic Deontic Assertions. Deontic Propositions have a core meaning which is usually represented by a verb that is the act, for example, to pay, to send, to receive, and to acknowledge. Our proposed DAM is populated with a list of performative verbs based on the work of Vanderveken (1990). Though Vanderveken has based his proposal on the speech act theory, we see that the interpretation of the performatives is similar to the deontic verb interpretation as proposed by Bucciarelli and Johnson-Laird (2005). We map our Performative Verb Ontology to the DAM when we implement the same in Protégé ontology editor. The degree of intention to fulfill the said deontic proposition is expressed through the use of modal verbs in language. We represent this notion as Deontic Modality in our DAM. We discuss Deontic Modality in details in section 6.5.4. The deontic assertions themselves have possible sets of deontic modality associated with each of them. Deontic Propositions are performed by through Acts. Acts maybe business activities, or communicative activities, but they may use, produce or somehow affect changes in other entities like Resource. In a business trade domain, the purpose of carrying out business activities would be to gain some value in their resources, like exchanging goods for money. Social Acts create Social Relations, and Deontic Proposition is one kind of Social Relation. Other examples may be of institutional propositions like marriages. Acts create a certain State of Affairs that is defined as a change in the world of discourse due to the act being performed. An example could be, I pay you 100 euros, (which is the Deontic proposition) and as a result of the Act (pay) the State of Affairs now becomes that (1) I am poorer by 100 euros (2) You are richer by 100 euros. State of affairs may themselves be Deontic Propositions, or a change in the state of a particular deontic proposition. In other words, we see that the state of affairs sets up precondi- 6.5 Semantic Analysis Representations: Discovering Semantic Relationships 133 Deontic Analysis Model Fig. 6.10. - 134 6 Unified Semantic Procedural Pragmatic Design tions for other deontic propositions to be created, after the first deontic proposition has been created by a social act. Also, we can visualize that deontic propositions may result as a post condition of actions. Deontic Proposition may be abstractly classified as being basic, nested (complex) or conditional deontic propositions. (Not depicted in figure 6.10). The simplest case or the basic Deontic Proposition is when there is a single intention of action is communicated. A complex Deontic Proposition results when a primary deontic proposition creates or implies a secondary (nested) deontic proposition and so on. A conditional Deontic Proposition consists of at least two individual basic deontic propositions, wherein one of them is a predecessor and the effect of that necessitates the second deontic proposition to be created. Thus we model this notion of deontic propositions being created, fulfilled, and conditional, etc., as deontic states.

Deontic Modality

Modality in linguistics may be of different types like epistemic modality, circum- stantial modality, deontic modality, teleological modality, and bouletic modality (Fintel 2006). We restrict ourselves only to the scope of deontic modality in this current paper. We analyze only the central modal verbs of can, may, will, shall, must; could, might, would, should. Other modal verbs may be interpreted to be one of the above basic modal verbs. These can be said to have the following meanings as per Palmer (1990) in his book on Modality and English Modals - (i) Epistemic Possi- bility (may), (ii) Epistemic Necessity (must), (iii) Epistemic W/S (will); (iv) Deontic Possibility (may, can), (v) Deontic Necessity (must), (vi) Deontic W/S (shall); (vii) Dynamic Possibility (can), (viii) Dynamic W/S (will). We adopt and include the deontic modal classiﬁcation of possibility, necessity and probability in our proposed DAM as deontic possibility, deontic necessity, deontic probability. Ninan (2005) has analyzed the difference between must and shall is that, must implies a necessity, whose denial would have repercussions. A shall on the other hand is a little weaker, since it indicates that the promised choice is probably the best alternative of some other promises. ‘I shall pay you’ implies that may be I have a choice of not paying you but, I still undertake the promise to pay you. ‘I must pay you’ implies that whether I like it or not, I am obligated to pay you. We propose that the imperative nature of the deontic proposition is made explicit using the modal verbs like must, shall, should, can, may in front of the expected act. For instance, a command - ‘You must send me 3 dozen bananas by Friday’, may become a request by ‘Please send me 3 dozen bananas by Friday’ or a query ‘Could you send me 3 dozen bananas by Friday?’ and so on. 6.5 Semantic Analysis Representations: Discovering Semantic Relationships 135

Types of Deontic Propositions

We now take up some simple illustrative examples to show how the DAM may be used, first as an aid to help extract the hidden knowledge and then to express it as semantics. The proposed DAM is targeted at knowledge engineers and designers who intend to model the domain ontology. We assume that a natural language description of the domain is available, and that our DAM will aid the knowledge engineer in parsing, interpreting and extracting the deontics. The natural way to do so is to use the DAM as one would use a conceptual modeling pattern that not only defines and describes the deontic concepts, but also provides the associations. The DAM also provides a list of defined ‘instances’ for deontic modality, deontic assertions, and acts. We also recommend that an additional input of linguistic thesaurus or the WORDNET (Web Resource) ontology may enable this process to be semi-automatic. As said before, we have three possible combinations for Deontic propositions: basic, nested, and conditional. We now provide an illustrative example for each of them.

Basic Deontic Proposition

We now demonstrate the use of the proposed DAM to analyze simple descriptions like - Peter must pay John 100 Euros. This is the basic deontic proposition which has the deontic core meaning to be to pay that is represented by act in the conceptual model. We see that the deontic modality is of that of necessity that indicates that it is an obligation. The execution of the act ‘to pay’ results in the state of affairs that Peter need not pay money to John,or simply we could interpret that Peter has fulﬁlled his social relation.

6.5.5 Nested or Complex Deontic Proposition

Deontic propositions may also be complex, which is composed of a number of basic deontic propositions, but they are all linked together by virtue of their pragmatics. We could analyze this ‘chain’ of deontic propositions by analyzing each individual deontic propositions and establishing their pre- and post-conditions of state of affairs. In ﬁgure 6.12, we see an example of one such nested deontic proposition. The deontic proposition is ‘John must allow Peter to leave early’. The social act in this case is the intention that permission for Peter to leave must be created. That is, John has to act in a certain way so that Peter is, thereafter, enabled to leave early. Here we see that on part of John, we have an obligation that he must act to create the permission for Peter to leave. As a result, either Peter is allowed to leave or he is not allowed to leave. If Peter is allowed to leave, this creates the secondary or nested deontic proposition that Peter may leave early. This is a permission indicating that Peter has a choice to leave early or not. 136 6 Uniﬁed Semantic Procedural Pragmatic Design

Conditional Deontic Proposition

In this example, the basic deontic proposition, ‘If Peter breaks the glass, he must pay for it’ is interpreted as a prohibition which carries with it the deontic necessity condition for fulfilment. Here the proposer is implicit, and could be a person, institution who owns the glass. The social act concerned is that the glass should not be broken. Peter is the person who is forbidden to break the glass. We analyze the possibility that if the glass is broken, then there are two possible states of affairs that could result: (a) the glass is intact, in which case there is no further proposition (b) the glass is broken, in which case, a conditional deontic proposition is now set up, that is Peter must pay fine. We may proceed to analyze this proposition further similar to the previous example for basic deontic propositions. The above mentioned examples indicate the possible use for DAM. We can apply the same to any chosen domain of discourse like health care, military modeling and simulations or business contracts. We shall see some illustrative uses of the proposed DAM in our two case studies later on. Fig. 6.11. Basic Deontic Proposition 138 6 Unified Semantic Procedural Pragmatic Design - i.6.12. Fig. etdDotcProposition Deontic Nested 6.5 Semantic Analysis Representations: Discovering Semantic Relationships 139 Conditional Deontic Proposition Fig. 6.13. - 140 6 Unified Semantic Procedural Pragmatic Design

6.5.6 ECA Rule Ontology: Prescriptive Relationships

The use of ontologies as knowledge repositories for facilitating semantic web applications is widely accepted. As with any other application, the need for supporting constraints, policies, rules is self evident. Event-Condition-Action rules are an intuitive choice for the same as has been proposed by Papamarkos, Poulovassilis & Wood (2003). Other alternatives like the proposed Semantic Web Rule Language 5 (SWRL) were also considered, but in view of our second objective, that is to provide an easy to use guideline for the na´ıve user,we chose to adopt the simple ECA rule approach. An ECA rule has a general syntax of: On EVENT if CONDITION then DO Actions. We build our ECA Rule ontology on the same principle as seen in figure 6.14. The event concept specifies the occurrence of any triggers, situations, orders, or incidents. The condition concept specifies the other requirements like state of affairs, current situation contexts, preconditions, post conditions of other actions and so forth. The idea is that on the occurrence of an event, a pre determined condition needs to be evaluated. And if the condition is evaluated to be true then the prescribed action is allowed. Action in the ECA rule ontology indicates not only physical activities, but could also be used for delegation of authority and rights. The above information is sufficient, from a data level software engineering perspective. However, from the domain knowledge perspective we need to capture further implicit knowledge like what caused the event? Who was responsible for the event? Who is affected by the event? What are the consequences? The answers to the above questions form the context for the decision to be made: whether the described rule is to be executed or not. Therefore, we now extend the concepts of event with relationships to the Five Ws (Carey, Kleiner, Hieb & Brown 2001) analysis approach: who, what, why, where and when. For example, a business rule in the fast food restaurant that the customer shall be refunded his/her money incase the food is delivered later than 15 minutes can be modeled using our ECA rule ontology as shown in figure 6.15. The ECA rule ontology could be used as a pattern to analyze the rules and conditions for any action or process oriented domain. We have used it for,modeling rules of engagement in our Defence Conceptual Modeling Framework Case study, as shall be discussed later. But, it could be as easily used for analyzing business policies and rules in an enterprise system. The ECA rule ontology may be used as a template and domain specific ‘specializations’ may be inferred to restrict the valid combinations allowable for each of the concepts identified above. For example, for the military case study project DCMF context, an actor or (who) was mapped to the local domain ontology for that case study, namely the DCMF-O. Details can be seen in chapter 8. This

5 http://www.w3.org/Submission/SWRL/ 6.5 Semantic Analysis Representations: Discovering Semantic Relationships 141 - ECA Rule Ontology Fig. 6.14. 142 6 Uniﬁed Semantic Procedural Pragmatic Design i.6.15. Fig. C ueOtlg:A lutaieExample Illustrative An Ontology: Rule ECA - 6.6 Semantic Concept View 143 mapping helped users in rapidly using the ECA rule ontology as an analysis tool to extract information from their domain. We carried out some user studies and survey for the same results of which have been discussed in Kabilan & Svan (2007).

The Five Ws approach

The Five Ws is a concept used in journalism for structuring a story of something. The principle is that a complete report must answer the ﬁve interrogative words: Who, What, When, Why and Where. Sometimes an H is added representing How. All these questions should be answered with necessary facts in order to get a complete report and the full story of something that has happened. This structure is common in news style and news reports but has also been used for police investigations. The same Five Ws approach has been introduced and used for military operations analysis as seen in works of Turnitsa, Kovvuri, Tolk, DeMasi, Dobbs & Sudnikovich (2004)and Carey et al. (2001). We shall details of the use of the ECA rule ontology in our case study for the military operations modeling domain in section 8.7.1.

6.6 Semantic Concept View

After having presented the different conceptual analysis patterns in the previous sections, we now begin the detailed discission of the USP2 Design. We discuss the Semantic Concept View in this section. The Semantic Concept View(SCV) would give us the vocabulary which describes the domain. It is analogous to the the thesaurus of any language. As reviewed earlier, the semantic vocabulary forms a fundamental component of ontology. Thus the identiﬁcation of concepts, their descriptive characteristics constitute the Semantic Concept View. A detailed discussion of design choices to be made in the process of designing an ontology for information has been discussed in the Ontology for Infor- mation Systems (O4IS) design methodology in chapter 5. We could also capture the ‘static’ concepts of the domain, both explicit and implicit, following current ontology design guidelines such as that of Uschold & Gruninger (1996) or METHONTOLOGY (Fernandez et al. 1997) or Noy & McGuinness (2001). These domain concepts are modeled as concepts in UML class diagram. Relationships between these concepts are drawn as UML associations. The associations capture the semantic relationship as well as the structural composition. For this phase, we adopt the basics of Chen’s (1976) ER model approach as discussed earlier. We also follow and adapt Storey & Purao’s (2004) verb phrase ontology for classifying relationships.

R We identify the concepts and their relationships; concepts may be physical objects, abstract processes, emotions, state of affairs and so on. 144 6 Uniﬁed Semantic Procedural Pragmatic Design

The process of analyzing and modeling the semantic concepts is actually a sub phase under the main O4IS design methodology for ontology design, and pertains to the actual modeling of the domain ontology. So the input prior to applying the USP2 Design would include: (i) Identifying the purpose, targeted audience, domain of interest, scope of the domain, functional and non-functional requirement analysis; (ii) Deciding on architecture for the targeted ontology (single-tier or multi-tier) conceptual/logical architecture and the physical architecture (single-multiple-hybrid physical); and (iii) Selecting existing ontology/KB/data models, reference ontologies, meta ontologies. This is essentially G7 Knowledge Analysis and G8 Knowledge Modeling steps in the overall O4IS design methodology. The knowledge analysis and knowledge modeling is to be an iterative process till the designer is satisfied that information satisfying the targeted application has been captured and modeled. One of the first decision that is to be made is the level or granularity of representation. This is to some extent guided by the purpose of application as well. R In case the purpose is only for illustrative purposes, for making domain knowledge explicit, for humans only, then only the Semantic Concept View (SCV) is sufficient. If the domain under investigation has more behavioral aspects, that is, it is more ‘action centric’ rather than ‘object centric’; obviously the description of the same cannot be covered totally by only the SCV. The Procedural Concept View is to be analyzed and represented as well. If the domain has normative issues like obligations, and regulations, etc., which are to be a part of the ontology as well, then we suggest that the Pragmatic Concept View is to be analyzed and represented. In all cases, the semantic concept view analysis is mandatory. The other two or a combination or the two are optional and depend on the nature of the domain being studied as well as the purpose.

6.6.1 Design Guidelines for the Semantic Concept View

To describe the method on how to model the semantics, we once again follow a pattern as: Name: Name of the design step. Input: Required input for this step to be carried out. Procedure: Instructions, guidelines on how to proceed. Illustration/Discussion: Illustrative examples, discussion and comments are included. Output: Describes the expected output or end result of this step.

Step 1 Identify the key concepts within the identiﬁed domain.

Input: Our identiﬁed domain of interest from the O4IS, G1 phase. 6.6 Semantic Concept View 145

Procedure:: For this step, the requirement analysis workflow loop from UPON would be useful. It gives a detailed description of how a glossary of terms, then concepts identified and taxonomy is built. As an aid, it would be advice able to set up some competency questions for the domain analysis, as a cross check. The answers to these questions will help in identifying the central concepts. Further questions based on these concepts will identify other related concepts. One should iterate till sufficient concepts and their characteristics have been identified. Illustration: For example, let us assume that our domain of interest is that of, say, cars. Then, the key concepts would be, entities or objects like cars, buses, SUV, car owner, customer and so on. Following our discussion on semantics, we then have to identify and extract the concepts, their definitions, delimitations, and their characteristics. Note that characteristics of entities could themselves be represented as concepts in the ontology. Most of the concepts are usually the subject or object of a natural language sentence. Their relationships or characteristics are often denoted through the verbs, adjectives or adverbs. For example, some competency questions for our cars domain would be:

Q. What are cars? Q. What different cars are there? Q. How can we describe them? Q. How can we differentiate between cars? Q. What can we use cars for?

Most identified concepts end up as classes in ontology, their individual characteristics as properties or facets or slots as they may be referred to in different tools/methods. The relations between concepts end up as associations, object property relationships (OWL). Output: A set of concepts, characteristics. At the moment, we have only a set of identified concepts, their definitions, some properties and possible relationships. This could very well be a natural language list, or a unordered set of data,at best a taxonomy or a glossary.

Step 2 Generalize/ specialize the concepts.

Input: Output from pervious step, design choice made in G4 of the O4IS, Standard upper ontologies like SUMO or Bunge-Wand-Weber ontology (Wand & Weber 1990) (optional). Procedure: The concepts identiﬁed in the previous step would be similar, could be synonyms, homonyms, could be a part of some of concept, and could be a kind of some other concept, and so on. 146 6 Uniﬁed Semantic Procedural Pragmatic Design

The next task is to build a lattice of concepts, where each layer on top is a generalization of a concept in the layer below. We have summarized the pros and cons of three strategies for this process, a top down, bottom up or middle out approach in section 3.7. We now explicate these with our suggestions for this design step. The designer needs to choose any one of the alternatives. It is possible to begin with one approach and to switch to any another approach as the development proceeds. As per our O4IS design methodology, the design choice of top down, bottom up or middle out should have been made in G4 (section 5.2.5), but if not, the designer needs to do it now for the execution of this step. Illustration/Discussion: We now illustrate the possible analysis via each of the three strategies discussed for our running case example:

Top Down approach

In the top down approach, we begin with the most generic concept that we would like to have in the ontology and successively include specializations below it. We decide the top most generalization, based on our domain and scope. In most cases, for this approach, we begin by adopting some previously established ontology or published standard ontologies. Upper Generic ontologies like IEEE’s SUMO or Bunge Wand Weber ontology or Open CyC are all possible choices. If, your domain relates to business enterprises, then you could use TOVE(Fox 1992) or Enterprise ontology as the starting point. If your domain is related to health care or medicine, you would use Open GALEN or UMLS or SNOMED clinical terms ontologies as a starting point. For our car scenario, if we take SUMO as a starting point, we would begin with “entity– physical object–....– vehicle” branch. As we can see, we probably would have to drill down several branches till we get the entities that we are interested in. We do not necessarily need all the information regarding entities and physical objects in general.

Bottom-Up Approach

In the bottom-up approach, we begin by identifying the individuals who deﬁne our domain. For example, for our domain of a car rental company, we begin by identifying each of the cars that belong to the company, we observe their registration number, color, year of manufacture, model, make and so on. These, as we see, are speciﬁc characteristics for each individual. Thereafter, following the ER conceptualization approach (see details in section 4.2.1), we group individuals having similar characteristics as a type. That means, we identify a concept ‘Car’ having the characteristics ‘Make’, ‘Model’, ‘Year’, ‘Color’ and so on. This is called generalization, and the approach we have just taken is the bottom up approach. We can further group concepts having similar characteristics in to another ‘generic’ concept. For example, 6.6 Semantic Concept View 147

‘Car’, ‘Bike’, ‘Bus’ are all ‘Motorized Vehicles’. A ‘Push cart’, ‘Bicycle’ is ‘Non-Motorized Vehicles’. They are all examples of ‘Vehicles’.

Middle-Out Approach

The last approach to be discussed here is a combination of the previous two approaches. In the top down, we have the disadvantage that we need to know before hand the top most generic concept that we should have in your domain ontology. Another disadvantage is that we do not know how deep our ontology is likely to be, as we would have to ‘specialize’ till we get to the individuals that we are targeting. For example, if our domain is the Car leasing company, then it would not be sufficient to identify only ‘car’, ‘bus’ and ‘bike’. We still need to identify the individual ‘cars’ and ‘buses’ that the leasing company owns. Similarly, the bottom-up approach, has its own disadvantages. It is more tedious and time consuming. We need to identify all individuals, study their characteristics and then generalize to get a concept. This approach is ideal, when we have a number of empirical case objects available for study and when we do not have any prior knowledge of the domain that we are studying. The optimum approach, is then the middle out approach, as recommended by Uschold & Gruninger (1996) (See section 3.8.1). We too recommend this approach as a first alternative for an Information Systems designer. In this Middle-out approach, we make use of previously gained and established knowledge. This could be from other literature, experience reports, technical reports, data models, and obviously other ontologies. Like in the top down approach, one should identify and collect the related ontologies to the domain that you are studying. In the above case example, we could study the SUMO ontology. We may not need the entire SUMO but only the relevant tree of information starting from the concept ‘Vehicle’. Having this prior information as a point of reference, we begin by looking up concepts from the reference ontology and the individuals belonging to our domain. Thus, we identify the concepts of ‘car’, ‘bus’, ‘motor boat’ and so on. Thereafter, its easier and faster to identify and capture the information of all individuals belonging to the identified concepts. Output: We can represent the concepts identified so far as: (i) a document list in natural language; (ii) Object or concepts using any conceptual modeling notation; Typically all identified concepts will be classes or objects in UML class diagram or object diagram respectively. The characteristics of the identified concept would be UML Class attributes; and (iii) Semantic Nets, topic maps are other representation forms that one could consider. 148 6 Unified Semantic Procedural Pragmatic Design

Step 3 Classify and organize the structure.

Input: Identified list of entities from previous step, Storey and Purao’s Verb Phrase Ontology, our recommendations on identifying structural relationships (introduced below in table 6.2). Procedure: In the previous step, we have listed and identified the concepts pertaining to the domain of interest. Now, we build the network of relationships between them. We adopt and follow Storey and Purao’s proposed verb phrase ontology as the basic classification structure as summarize in section 6.3. The first and foremost of them would be the Hierarchical structure. This association describes the vertical generalization-specialization relationship. In other words, we first associate the IS-A (structural, or a ‘kind of’) semantic relationships between the concepts, to get taxonomy of the identified concepts. We refer to the status category of the verb phrase ontology as our reference set of patterns for identifying the structural relationships. For example, we would associate Car IS A Motorized Vehicle, Motorized Vehicle IS A Vehicle. Here, we have a slight difference from the typical object modeling philosophy or the UML entity class modeling convention. Since, we are modeling concepts for ontology, we need to visualize and model the concepts and their characteristics care- fully. In ontology we have object properties and data type properties. Data type properties are the basic characteristics of a concept which cannot be further subdivided or analyzed. For example, an Invoice has order date which is of the data type ‘Date’. This, we would model as property of the concept ‘Invoice’ itself. The object properties are concepts in themselves. That is, they can have other features and properties themselves. For example, a ‘Category’ of a ‘Car’ could be ‘Sedan’,‘Family Combi’, ‘All Wheel Drive’, ‘Minivan’ and so on. Each of these categories themselves can be described through a set of features. (For simplicity, in our case scenario we are assuming that sedans cannot be all wheel drives) So, how would we model these relationships conceptually using ontology modeling principles? Again, we refer to the verb phrase ontology and the other primitives of the structural sub category of status as summarized by Storey and Purao. Follow- ing their suggestions on specifying context specific relationships, we have narrowed down their list of structural status primitives to present a set of ‘structural relationship patterns’. Illustration/Discussion: We model semantic relationships between the concepts as seen in figure 6.16. Car has a Color. MyCar is red and Tom’s Car is Blue. We associate a relationship between the concept Car and the concept Color, has color. We name the structural primitive is-part-of to have a semantic name as has color. We also see that the colors red, yellow and blue have been modeled as individuals who are structurally related as is-instance-of with car. Similarly we have mod- 6.6 Semantic Concept View 149 eled that car body is-part-of a car, and that sedan, SUV, minivan are all kinds of car body. R Note that we use here the structural relationship ‘is-a’ and not ‘is- instance-of’. We use ‘is-a’ for the kind of or type of generalization and not for the ‘instance-of’ relationship. We note that an ‘is-a’ relationship from an ontology perspective is not identical with the same concept as represented by the entity relationship diagramming convention. In UML class diagram, a generalization (is-a) is represented by an arrow with unfilled head. It implies that all concepts (class) below a given concept are ‘subclasses’ of the parent class. In ontology, we must remember that we support multiple inheritance, and so a particular concept may inherit from more than one parent class. So strictly speaking, an is-a relationship from the ontology perspective is not always and only a ‘sub class’. In a conceptual representation we have as in figure 6.16, car and color are concepts (classes) shown in the ovals, the relationships are shown as lines, and the name on the lines depicts the name of the relationship. The individuals are modeled as ‘objects’ or literals in the rectangular boxes. Here we have followed the RDF graph notation for describing tuples. Sedans, SUVs and minivans are different car body types.

Fig. 6.16. Identifying Concepts and Structures

Let us now add some more concepts to our car scenario analysis. MyCar is a sedan while Tom’s car is an SUV (or an All Wheel Drive). Peter has a mini Van. We can see the slight extensions to our conceptual model in ﬁgure 6.17. We have modeled the relationship between MyCar and the car body type sedan as an instance-of structural relationship. 150 6 Uniﬁed Semantic Procedural Pragmatic Design

Fig. 6.17. Extending Concepts

The level of analysis and granularity desired, as discussed earlier in Guideline G5 (see section 5.2.6), is decided by (a) the scope of the domain to be studied, (b) the targeted purpose for the ontology. If all that we needed to know was what kind of car that Tom, Peter or I had, then the level of conceptualization as shown in figure 6.16 and figure 6.17 would suffice. However, if one needed to know more about my car or Tom’s car, then our modified set of competency questions would be:

• what are the features of a sedan? • what differences does an SUV have from a sedan? • How many people can travel in a mini van?

Then the above conceptualization is not enough. Then, we need to dig deeper and specialize the concepts further. In ﬁgure 6.18, we have identiﬁed some characteristics of Sedan, SUV(Sports Util- ity Vehicle) and Minivan, which could answer our competency questions. Some additional input for these concepts are described after survey from the domain as:

• An SUV is an terrain vehicle with the comfort of a personal car. • An SUV has a ﬁve door Combi body. • An SUV can seat either ﬁve or seven people. • It has a four wheel drive, that is you can steer and control both the back and front wheels. • It has a powerful engine, usually more than an ordinary car

Similarly we can analyze for other models of the cars as well. We generalize to introduce concepts called seating capacity and steering control. Are they to be made characteristics of the concept Body or characteristics 6.6 Semantic Concept View 151

Fig. 6.18. Extending the Structural Relationships

of the concept Car? This is a modeling issue. In conceptual modeling there are no absolutely right or wrong way of modeling the real world. Some may choose to model seating capacity as a datatype property of the concept car, of the type integer. Others may choose to model it as a feature of the car body concept. We can resolve this dilemma, if we ask ourselves – Is the specialization feature seating capacity and steering control a distinguishing feature of the concept car body or the concept car? It is the body types that are distinguished from each other by a series of features, two of which are the seating capacity and steering control. Another example would be number of doors and so on. (The Car Body is the structural part of the Car.) R We recommend that the concept should be grouped by similarity, their properties associated with the nearest concept node where it can distinguish between concepts. In the ﬁgure 6.19 we have now modeled the seating capacity and steering control as ‘properties’ of the car body. Since, we have inheritance of properties, and as we have already established that a sedan is a body, seating capacity and steer control are properties of a sedan as well. But we still now have to put in the condition that a sedan can seat maximum 5 people and that it can only be a two-wheel drive steering control. Such constraints are known as axioms in ontology. Therefore, the next step for us is to build in axioms in our ontology. 152 6 Uniﬁed Semantic Procedural Pragmatic Design

Fig. 6.19. Adding Semantic Relations

Output: At the end of this step, we should have iteratively discovered more concepts as sub concepts or related concepts. We ﬁrst have the hierarchical (structural) taxonomy and that ‘grows’ as we add more and more related concepts. At the ﬁ- nal iteration, we should have a semantic net of concepts, as we have seen in our example above. The representation formalization should be any graphical language like RDF graphs, conceptual graphs, topic maps, semantic nets, ORM (Object Role Models), UML class diagrams. For the last two formalizations, we recommend that the designer should follow the ODM standard for facilitating mapping to OWL later on.

Step 4 Deﬁne the Characteristics and Features. (Properties and Facets).

Input: The conceptual model from the previous step, Noy and McGuinness’s 101 ontology design guidelines. Procedure: Once we have identiﬁed and formed the structural hierarchy of concepts, we need to add the characteristics and integrity constraints for the same. For this, we recommend the Noy & McGuinness (2001) guidelines as a thumb rule for identifying the different features of the individual concepts and the constraints on them including cardinality restrictions and so on. The characteristics of a concept are simple properties which cannot be further subdivided or it is not required for the level of abstraction chosen. 6.6 Semantic Concept View 153

For example, a Purchase Order can have a property for the order date and date- sent that are ‘atomic’ features and can easily be identified as being a ‘date’ data type. More complex characteristics like the office address of the car rental company would be defined as an ‘object property’. The ‘address’ concept in this case having several other ‘atomic’ characteristics as ‘street-number’, ‘postal code’, ‘city’, ‘telephone’ and so on. In this step, we also recommend that we add preliminary definitions for the identified concept. Later, when we implement our ontology, we can annotate with WORDNET for precise definitions, synonyms and other linguistic enrichments. Illustration/Discussion: We do not discuss in detail the process of identifying ‘properties’ of concepts herein. A commonly asked question is how does one decide if an identified concept should be an OWL class, or OWL data type property or OWL object type property. R If a concept has only one dimension or characteristic which can be defined in existing types like integer, array, time, enumerated list and so on, then we should model it as a OWL data type property. If a concept in itself has other characteristics and can be used in several other contexts,then we recommend that it be modeled as an object property. In this case, Seating Capacity can be described only as the number of persons that can sit at a time in a particular body type of a car. A coupe can seat only two people, a sedan five people, SUV five to seven people and so on. Hence, we choose to model Seating Capacity as OWL data type property of the type Integer. Though the car body is a property of the Car, we choose to model it as a class concept. The body has several associated characteristics like steering control, number of doors, seating capacity and so on. In our scenario, a car would have registration number, engine chassis number, insurance policy number and so on. Car Body Types could have properties like manufacturer, patent number, horse power, safety criteria specification and so on. Output: We have a conceptual model where concepts and their characteristics are noted. We could use an ER diagram notation like UML for the same purpose.

Step 5 Deﬁne the axioms. (Integrity constraints).

Input: The conceptual models from the previous step. Procedure: We should now try to identify the constraints on the concepts and describe them in natural language first. These shall then be expressed as OCL or CL (if following the ODM specification) for UML class diagrams, and finally as DL (Description Logic) axioms in OWL ( if OWL is the chosen knowledge representation formalization for the ontology). The design objective is to make explicit all such domain constraints explicit in one form or the other. If our targeted purpose was only to chart the domain knowledge for human understanding then the conceptual models at the end of this step are the final artifact desired. The final step is the 154 6 Unified Semantic Procedural Pragmatic Design translation of the conceptual models into formal ontology representation. For our Car example, we have some constraints like:

1 A sedan has only four doors. 2 A sedan can be steered by only the front wheels. 3 A sedan can seat maximum five people. 4 A SUV has five doors. 5 A SUV can seat either five or seven people. 6 A SUV has a four wheel drive. 7 A minivan has five doors. 8 A minivan seats nine people. 9 A minivan can be steered by the front wheels only. 10 A Car can have only one body. 11 A Car can have only one color 12 ......

Some of the constraints can be represented using the cardinality options in an UML class diagram or the equivalent maxCardinality restrictions in DL for OWL. For example, the last two constraints listed above can be modeled as cardinality restrictions in UML as figure. In OWL, we can use the owl:FunctionalProperty with the owl:ObjectProperty to define if the cardinality is to be one or more. If, we wish that a specified concept can have a cardinality between 2 and any other number, we can then use the minCardinality and maxCardinality restrictions. For modeling the axiom that a sedan can seat only five people. We define a restriction on the seating capacity property of a sedan. We set the ‘has Value’ option to 5. We also restrict the steering control to a two wheel drive. It is not necessary that one has to write the DL axioms themselves, as the tool for ontology implementation would support and help in the process. Note that though we have referred to the OWL language equivalents for explaining the constraints, it is not necessary to use OWL as a specific language for representation at this stage. Output: An output at this stage would be at least a natural language description of what are the constraints that define the relationships between the concepts. If we are using UML for the conceptual model representation then we recommend the use of OCL or CL following the ODM specification to record the constraints.

Step 6: Implement the Ontology.

Input: Conceptual model from the end of step 5, an ontology editor and development environment like Protégé. Procedure: In this step, we now start building our ontology. If the selected tool for ontology development supports import of UML models or XMI files, then one may directly import the UML class diagrams. 6.6 Semantic Concept View 155

If the tool support is not available, then we would have to create the ontology manually using the mapping conventions and the conceptualization features discussed so far. For this research, we use Protégé Ontology editor. We do not discuss the steps for creating the classes, properties, and DL axioms in OWL here. We refer the interested reader to the tutorials for adding these in Protégé Ontology editor from CODIP project and the Noy and McGuinness guidelines. Protégé ontology editor has a number of useful plugins as we shall see during our case studies later. Here, we would like to introduce the OntoLing plugin 6, which interfaces the WORDNET as a linguistic knowledge resource to Protégé OWL editor. R Once we have some of the identified concepts input, following the same middle out approach, we recommend that we search on the class names in the linguistic resource, and choose to enrich you class concepts with word sense definitions that match your domain closest. Using the same selected word sense, ontoLing also generates sub concepts for the selected concept. We can semantically enrich our ontology by associating the synonyms, hyponyms and glossary terms as well. We can also map to other existing ontologies using the Prompt plug-in available in Protégé. Illustration/Discussion: A partial screenshot of our implementation with the linguistic enrichment as described above looks like in figure 6.20. Output: The output at the end of this step is the implemented ontology in the chosen ontology language using the chosen tools.

Step 7 Populate the ontology. Deﬁne the Individuals.

Input: Ontology implemented in chosen ontology editor, documented list of identified individuals of interest. Procedure: As we have discussed earlier, a knowledge base constitutes of both the conceptual schema as well as the individual facts that are captured in it. Hence, once we have designed the ontology ‘conceptual schema’, we need to populate it with individuals from our domain. That is, we need to create ‘instances’ of the classes that we just created. This is also a means of evaluating our design. Any design flaws or erroneous assumptions made in the conceptualizations will emerge now. If you cannot define your individuals accurately in the ontology,if you find that there are information that cannot be input in to your designed ontology, if there are missing information or relationships, then you need to go back and iterate through the previous steps to enrich the conceptual model further.

6 The OntoLing Tab is a Protégé plug-in that allows for Linguistic Enrichment of Ontologies. Available at http://ai-nlp.info.uniroma2.it/software/OntoLing/ 156 6 Unified Semantic Procedural Pragmatic Design

Fig. 6.20. Ontology Implementation in Prot´eg´e Ontology Editor

R We propose that all concepts that we initially discovered to have the structural relationship as instance-of in the ﬁrst step, should be modeled as individuals. Illustration/Discussion: We populate our car ontology by creating MyCar, Tom’s Car, Peter’s Car as instances. We also create the colors red, yellow, blue as instances of the concept color. Output: We now have our proposed domain ontology. R With this we come to the end of our Semantic Concept View description. In this section we have introduced our proposal for identifying structural relationships between concepts. The SCV as we have seen so far is explicit in establishing the vocabulary in use for a particular context or domain of interest. In the next section, we shall enrich our SCV with procedural aspects, that is how concepts react to each other,or what are the cause-effect of certain actions.

6.7 Procedural Concept View

As discussed previously, the behavioral aspects or the dynamic (perdurant) characteristics or the exchanges between different concepts need to be identified and captured. The Procedural Concept View (PCV) would analyze and give us how the semantic vocabulary could be associated with each other. This is analogous to the 6.7 Procedural Concept View 157 grammar and rules that a language should follow. Again we refer to Storey and Pu- rao’s verb phrase classification, and we make use of their interaction category and the temporal, spatial primitives of the status category of semantic relationships between entities. A Procedural Concept View describes the intended course of action, intentional plan, and can relate between the embedded knowledge derived from the domain analysis and the intended purpose. This includes mappings to a behavior ontology, functional models or task, process ontology, as well as additional stereotyped associations for representing sequences (structure), pre-conditions and post conditions. One such aspect would be the business rules that govern the business actions. A business rule of the type - “If an event A occurs and condition B is satisfied then do action C” maybe analyzed and captured using the ECA approach. We have proposed ECA rule ontology as a pattern for analyzing and representing the same. Details of the proposed ECA Rule Ontology may be read in section 6.5.6. Linear Temporal Logic constructs may be used for analyzing the ordering of events in time. We shall see an illustration of this in one of our case studies. We have used BPMN as another representation language for describing contract compliant business processes in another of our case studies. A correlation between the semantic concepts identified as ‘objects’ in the Semantic Concept View and the ‘flow’ diagram (Activity, Process, and Sequential Flows) in Procedural Concept View (using BPMN) has been discussed in Kabilan(2005).

6.7.1 Design Guidelines for the Procedural Concept View

Step 1: Discovering the central actions.

Input: The Semantic Concept View, Performative verb ontology based on Van- derveken’s classification. Procedure: For the procedural concept view analysis the domain must be action oriented. That is the scope should have some characteristics that are dynamic, changing, temporally and spatially displaced. Typical example would be processes, activities, rules of a game, etc. In short anything that describes how a particular sequence of activities may be connected to each other or how they may occur. Every such domain will have the fundamental concept of an Action, or a process in addition to the fundamentals of Actor, Object, and Attribute as seen in the SCV. The action concept will be related to the other identified concepts from the SCV. Ac- tions or processes are almost always identified by the ‘verbs’ in any natural language representation. The Oxford English Dictionary defines a verb as: A verb is a word that denotes what a person or thing does, and can describe:

• an action, e.g. run, hit. 158 6 Uniﬁed Semantic Procedural Pragmatic Design

• an event, e.g. rain, happen. • a state, e.g. be, have, seem. • a change, e.g. become, grow.

Vanderveken has compiled a categorization of performative verbs (action verbs) in English language based on the Speech Act theory, that may be referred to as an aid to identify the ‘action’ in the domain of interest. Illustration: In our running example of the car rental scenario, we can identify that the basic actions involved are ‘leasing’, ‘payment’ and ‘returning’ of the car. The actors involved are the customer, the car owner and maybe the car rental owner if the car owner is different from the car rental owner. Output: The output at this stage can be listed as a textual description of the different actions and identified actors and their roles. The identified actions may be optionally included in to the original Semantic Concept View designed at the end of the previous step. Figure 6.21 illustrates two identified actions leasing and payment added to the original SCV model from the previous step.

Fig. 6.21. Procedural Concept View: Car Rental Illustration 6.7 Procedural Concept View 159

Step 2: Identify the functional relationships between entity-action-object.(Object/Actor-Action functional relationship)

Input: Identified list of actions, Chen’s ER model approach, proposed functional relationships (6.3). Procedure: In this step we establish how the action concept will be functionally related to the other main concepts of the domain. We concur with Storey’s identification of an entity, action and an artifact(object); an entity is any agent capable of carrying out the identified action, while an artifact cannot independently do so. An artifact may be the cause or used by the actor (entity) in order to carry out the action. After having identified the performative actions in the previous step, we now need to identify the entities and objects that are relevant to the identified action. Thereafter, we establish the nature of functional relationship between them. We use Chen’s basic ER model (section 4.2.1) to help us identify the entities, actors, roles involved in the domain. R We recommend the use of the functional relationships patterns (6.3) as a look-up to establish the semantic relationships. Illustration: For example, in our example of a car rental enterprise, so far in the Semantic Concept View(SCV), we identified types of car, the car leaser (actor) amongst others. The action perspective of this scenario are ‘the leasing’, ‘the payment’, and ‘the return of the car’. The questions we now need to ask to discover the functional relationships are: Who can do the ‘leasing’? How is it done? What can be leased? Who can do the payment? What are the payment methods ? And so on.

Thus, we discover that the leasing action is related to the car rental owner, as the actor who can do the leasing and the customer is the ‘leasee’. The customer makes the ‘payment’. The leasing can be done via an agreement and exchange. The functional relationships identiﬁed is integrated in to the conceptual model obtained from the SCV. Figure 6.22 shows the functional relationship of the example. For simplicity we have removed some of the semantic concepts from the SCV for the car rental scenario. Output: A SCV modiﬁed with entity-action-object functional relationships.

Step 3:Identify Action-Action Functional relationship.

Input: The modiﬁed SCV from previous step, Functional action-action relationship patterns (table 6.4). 160 6 Uniﬁed Semantic Procedural Pragmatic Design

Fig. 6.22. Procedural Concept View: Extended Car Rental Scenario

Procedure: It is possible that identified actions or processes are related semantically to each other. For example, an action A can occur because action B has happened or Action A is a part of Action B. We have summarized a set of semantic patterns for relating actions in table 6.4. Illustration: In our running example, we have identified that ‘leasing’, ‘payment’ and ‘return of the car’ to be three actions. Payment is-a-sub-action of Leasing. Return of the car is a pre-requisite-for payment. Output: Again the identified relationships may either be kept in a text tabular form or added on to the conceptual model.

Step 4: Identify Action-Action Temporal relationship.

Input: The SCV, the identified actions from step 1, action-action temporal relationships from figure 6.8. Procedure: In addition to discovering how the activities are related to each other, to the entities responsible for performing the activities and so on, we also need to identify the temporal sequence in which they can occur. Like for example A occurs after B, A starts before but ends after B and so on. Illustration: In our example, Leasing starts before and ends after payment is completed. Car return starts after Leasing starts and ends before the end of Leasing. Output: We add the identified relationships to our tabular list of relationships or directly to our conceptual model. 6.8 Pragmatic Concept View 161

Step 5: Identify Action - dependencies and Conditions. Using Event Condition Logic.

Input: The combined list of actions and their functional relations, temporal relations. ECA rule ontology for prescriptive relationships. Procedure: Similar to the previous two steps, in this step we discover the dependencies like pre-conditions, post conditions, causes- and desired effects associated with actions. For this, we base our pattern ECA rule model on the Event Condition Action paradigm. Details of the ECA model is discussed in section 6.5.6. Illustration: If the car is returned later than agreed then the customer has to pay extra payment as penalty. Output: The Procedural Concept View as a Conceptual graph or UML conceptual model. R At the end of the Procedural Concept View, we would have a conceptual model for the domain. As we shall see in our case study, we can further extend the Procedural Concept View to get more business process model like visualizations. We propose a detailed methodology called Contract Workﬂow Methodology to deduce such procedural views from the Semantic conceptual models in section 7.12.3. We shall also suggested workﬂow like patterns for deciphering the same using BPMN in section 7.12.5.

6.8 Pragmatic Concept View

The Pragmatic Concept View of a domain is related with practical issues like how should the business process be executed, how should a cup of tea be boiled? It differs from the Procedural Concept View as the former deals more with implicit nuances and underlying linguistic structures and the latter is still limited to human- prescribed set of rules, constraints and procedures. The Pragmatic Concept View (PrCV) provides the context and relevance for the semantic and procedural analysis done in the previous two views. To give an example, a recipe for making tea would be a procedure. But for making John’s special tea, one needs the pragmatic concept view as well. Pragmatics cover a wide range of topics from linguistics, deontic, functional grammar analysis and so forth. The idea behind this research is to put forward patterns representing some of the prevalent theories that may be easily used by the Information Systems designer in carrying out the analysis. For this purpose, we propose a Deontic Analysis Model (based on deontic logic) as a pattern for analyzing the nature, extent (modalities) of obligations between actors involved in any domain. For the pragmatic analysis, we choose the deontic of a situation as one possible aspect to analyze. Speciﬁcally, we are interested in the analyzing the deontic modalities of the domain and its subsequent implications on the semantics. 162 6 Uniﬁed Semantic Procedural Pragmatic Design

For example:- (a) Pass the salt. (b) Please pass the salt. Example (a) is an order while example (b) is a request. The modalities of the statement are what differentiate the semantics of (a) from (b). When the objective of domain knowledge capture is to make these conceptualizations, it is assumed that they will be used in some speciﬁc applications for a speciﬁc purpose. The conceptualizations themselves are intended to be generic and application independent. Say, we are now interested in an intelligent agent where these statements are processed and actions are to be carried out, that necessitates that the difference between an order and a request is understood by the agent. Details of the DAM is presented in section 6.5.4. Again from Storey and Purao’s work, we have a list of semantic patterns to help identify the pragmatic relationship between entities as listed in table 6.5.

Table 6.5. Pragmatic Relationships from Storey’s Verb Phrase Ontology Primitive Example A wants to be B intent Customer Product A attempts to become attempt Customer Product owner of B A becomes B transition Customer Product Status Primitive: Customer Product A dislikes being B intent Customer Product A attempts to give up B attempt Customer Product A gives up ownership of transition Customer Product B

In the table 6.5 we see that Storey and Purao have proposed a change of status occurring as a life cycle in the status primitives defined. We have illustrated the case for one such primitive ‘is-owner-of’,similarly the same change of status primitives are applicable for other status primitives as well. In the table 6.5, ‘A’ and ‘B’ stand for any of the status primitives identified by Storey and Purao. This helps us resolve the pragmatics for the Actor-Object relationships, we still have to classify the shades of implicit understanding associated with per formative actions, or speech acts as we know them. For this purpose, we make use of the speech act theory and propose a Deontic Analysis Model (see details in section 6.10) as a pattern for analyzing specifically the modalities of an Actor-perform-Action relationship, for example, the implicit meaning behind Actor action, Actor action, Actor action. The pragmatic concept view encompasses the nuances that language could build in using the above mentioned semantics and procedural view. We also restrict our- 6.8 Pragmatic Concept View 163 selves currently to interpretation of prescriptive norms like social rules, legal obligations and normative constraints. For example, using the same English words, and following the grammar rules, different authors may compose different connotations. The ‘Big Apple’ refers not to a physically big apple fruit but to the city New York. The statements: (i) “You must taste this cake”; and (ii)“You could taste this cake” differs in their pragmatic implication that in the first case (i), the listener has no option but to taste the cake in a normative world where we interpret this as an order. While in the second case (ii), the listener has a choice whether he would like to taste the cake, we interpret this as an permission or offer. As stated earlier, we are interested in the analysis and representation of domain pragmatics for human understanding in the context of Information Systems. But we also need to capture the context in which a series of events or actions are taking place, because identifying a single event and analyzing it for the actor-action-object relationship would not provide us with the entire scenario. Intentions, beliefs and the force behind these acts is also a key domain concept. For example, to capture the intentional belief or the change of status primitives, we need to delve more deeply into the mind-set of the actor who is performing or intends to perform the action as well as the actor who is intended to be the beneficiary of the aforementioned act. Therefore, we further complement the Actor Actor set of patterns by taking help from Vanderveken. Vanderveken has extended Searle’s speech act theory (Searle 1969) and analyzed the English language for performative verbs from the perspective of the actor initiating the performative verb (speech act verb as it is called) and the actor who is the intended listener, recipient or target of the ‘perform’ primitive. (See details in section 6.4.) The Pragmatic Concept View is an optional design choice that the Information Systems designer has to follow only if the targeted application so requires it.

6.8.1 Design Guidelines for the Pragmatic Concept View

The basic approach and process to be followed for the pragmatic concept view design is similar to the ones followed for the Semantic Concept View and the Procedural Concept View. Hence, we do not describe the method in detail but list the main highlights below:

Step 1: Use Performative Verbs Ontology to discover the intent behind the action.

Input: The SCV, Performative Verb Ontology. Procedure: To further understand the intent or thinking behind the actor doing the action and the intended (targeted) actor,we suggest that the designer use the performative verbs ontology based on Vanderveken’s semantic analysis work. We use the performative verb ontology to identify the performance implied in the situation 164 6 Uniﬁed Semantic Procedural Pragmatic Design and to determine the nature of the intended action, if it is declarative, assertive, commissive, expressive or directive. Identify the English verbs and the modal verbs, use the performative verb ontology as a look up to match the type of performative verb. This step helps in discovering the deontic, or other pragmatic aspects to be modeled in the next steps. Illustration: In our car scenario, we have the customer who wishes to hire a car, which is an expressive. The car rental agency who advertises to rent out cars, which is a commissive. The customer who orders a car to be booked, which is a directive. The car rental agency guarantees the safety of the rented car, which is a declarative. Output: Identiﬁed actions, their nature and type of performative verbs.

Step 2: Use Verb Phrase Ontology extracts to analyze the pragmatic relations.

Input: The analyzed Semantic Concept View, and the SARs, the output from step 1 with the identified performative actions. Procedure: Analyze the pragmatic relations between actors and objects following the set of relationship patterns as illustrated in the table 6.5. Illustration: In our running example, we have identified the actors customer, lease rental owner. We have identified basic actions like hiring, payment, return of car earlier. Applying the SARs, we first have the structural relationships between the entities in the SCV. We apply the Pragmatic relationships to see that the customer de- sires to hire a car preferably blue. But in the event of the said car being unavailable, the customer hires another alternative car. Thereafter, he returns the hired car. Output: The SCV is enriched with the identified performative actions and their action functional and temporal relationships to each other and the identified actors as per the proposed SARs.

Step 3: Use Deontic Analysis Model to analyze the deontic aspects.

Input: The SCV and the DAM model. Procedure: If the domain of interest has deontics involved like in the business domain where one actor is allowed or prohibited from doing certain actions, or in the medical domain where doctors are ethically obliged to take certain procedures etc, then we recommend that the designer make use of our Deontic Analysis Model as well to further complement and capture the modalities of these performative actions. Illustration: In our case scenario, we have the basic deontic proposition that the car rental agency offers to lease out cars against a pre-determined payment. A customer who hires a car is thus obliged to pay for the rented period. There are nested deontic propositions involved as well. For example, the car rental agency is obliged that he provides a car in conformance to the stated conditions and in 6.8 Pragmatic Concept View 165 good working order. Likewise, the customer is obliged to return the car in the same condition as received and within the agreed time frame. Output: A conceptual model using the DAM as a template representing the iden- tiﬁed deontic propositions, social acts, expected performance, and obligation, etc. Figure 6.23 illustrates an example of the pragmatic concepts for the car rental scenario.

Fig. 6.23. Pragmatic Concept View Car Rental Illustration

R In this chapter, we have presented (i) Our proposed sets of Semantic Analysis Representations that include semantic relationships for structural, temporal, functional, deontic and prescriptive relations; (ii) Overview and design rationale for the USP2 Design; (iii) Detailed design guidelines for the Information Systems designer to analyze and conceptualize the semantics, procedures and pragmatics of the domain. In the next two chapters, we shall see how the proposed O4IS methodology and the USP2 Design have been put to use in different case studies.

O 7

Case Study I: The Business Contract Knowledge Management Project

In the previous chapters we introduced our design methodology for building ontologies. Now, we move on to the next topic of interest in this thesis, namely how do we develop and use ontologies for Information Systems?. We have carried out exercises in conceptualization of domain knowledge in various fields, and we choose to describe two case studies herein. The first case study relates to the world of business contracts. And the targeted use of the proposed contract ontology is for the contract execution, compliance checking with business workflows, integrating/mapping to existing business processes, exception handling, and performance monitoring, etc. The rest of this chapter is structured as shown in figure 7.1. We discuss the role of our proposed O4IS design methodology and the USP2 Design in section 7.7. In section 7.1 we describe the background and context for the business contract knowledge management case study. We summarize some of the salient related research in section 7.4. We introduce and describe the proposed Multi-Tier Contract Ontology and all its components in section 7.8. The Procedural Concept View for this case study is a specialization of the general design guidelines proposed in the previous chapter. We propose a Contract Workflow Model as a Procedural Concept View suited for extracting the procedural aspects implied in a business contract. We put forward this methodology for deducing Contract Workflow Model (CWM) in section 7.12.1. We conclude this chapter with a discussion of the results obtained in this case study (section 7.14).

Fig. 7.1. Case Study I: Disposition 168 7 Case Study I: The Business Contract Knowledge Management Project

Most of the work done in this case study has been covered in Kabilan (2003), and also published in (Kabilan & Johannesson 2003, Kabilan, Johannesson & Rugaimukammu 2003, Kabilan & Johannesson 2004, Kabilan 2005, Kabilan, Zdravkovic & Johannesson 2005). In the objective of keeping this thesis concise we present only an overview of the work done in this case study. We refer the interested reader to the papers mentioned above for details. We will review the work done in this case study only with reference to the O4IS design methodology, the semantics design and the uses that the proposed ontologies has been put to.

7.1 Case Study I Background

Ever since humanity started trading, business trade relationships have been forged and carried out. With subsequent developments in the realm of information technology, especially the Internet, the horizon and scope of business trading has increased. E-commerce standardization efforts aim to bring the small and medium scale en- trepreneurs at par with established corporate players. A key issue facing the Small and Medium scale Entrepreneur (SME) beginners, is the need to be competitive yet efficient, reliable yet fast to grow. A global pool of re-usable knowledge resources paves the way for promoting such trade relationships. One such knowledge application domain is in the realm of legal business contracts. Open, available contract knowledge should help the business entities in understanding their contractual obligations and their expected fulfilment business behavior. Business legal contracts are testaments to the business trade relationship established. The business contract is like a blueprint for expected business processes and activities to fulfil the agreed trade relationship. Legal jurisdiction governs and sanc- tifies the terms and conditions as expressed in a business contract. Hence, the need to integrate the contractual terms and conditions into the regular business process workflow is apparent. A profitable and efficient business workflow should conform or adhere as closely as possible to the expected behavior pattern of the contractual obligations. That is, ideally a business process should be modeled based on the agreed contractual terms and conditions. However, understanding and interpreting the contractual terms and conditions (as expressed in legalese) is not an easy task for the business entrepreneur or the Information Systems designer. Each of the users of the same legal business contract has a different purpose for interpreting the contractual terms. Focusing on legal business contracts alone, we see that the same contract can be viewed from three different perspectives as: (also illustrated in figure 7.2).

• Information Technology, Information System and Software Agent. • Legal jurisdiction, regulations and government policy. 7.1 Case Study I Background 169

Fig. 7.2. Three Perspectives of Business Contract Domain

• Business process, commercial trade practice.

The need for translation, understanding and interoperability between the three perspectives of the contract is much needed. Starting from the legal language used in a legal business contract an interpretation to a more easily understandable human language and hence forth to machine-understandable language is needed. To understand the nature of the research problem, we present a closer look at the three perspectives of the legal business contract below:

Information Technology, Information system, Software Agent.

One of the foremost requirements of any information management system is co- herency and precise clarity, which should enable anyone to understand the purpose, meaning and implication of any such information system. The same applies to the ﬁeld of contract management. Contract management software tools available today mostly adopt a document centric view of a contract, which is processing a contract as a physical or electronic document containing text and data. Some researchers like Karlapalem, Dani & Radha (2001) have modeled the contract terms and obligations as choreography of processes thereby promoting a process centric view of a contract. The approach is valid and sound, however certain aspects like the semantics or implied implications of a contract are not successfully handled. The third legal centric view adopted by the legal domain experts interprets implicit and explicit aspects of a contract. However it is at times complicated for the non-legal contract user to understand. None of the three prevalent approaches for handling contract management alone are sufﬁcient enough or are clear, precise enough to be of much use to the diverse users of contractual information. There is a need for a more coherent and integrated 170 7 Case Study I: The Business Contract Knowledge Management Project approach to model and represent contractual information. Recent efforts like that of the Semantic Web, which aims at making the Internet machine-readable and searchable source of information, could be one such approach for contract information management. In this case study, we propose a methodology for contract information modeling, representation and interpretation using an approach that is a combination of the document centric, process centric approach methodologies and the legal centric perspective of the contract. This research views legal business contracts as legal instruments containing not only meta-data information but also is a choreography of processes which are executed through business performances. For this purpose, we draw upon the O4IS design methodology to model the core business contract related ontology suite. We also make use of the USP2 Design for analyzing the different perspectives of the business contract domain, as we shall discuss shortly.

Legal Jurisdiction, Regulation, and Government Policy

Contracts are ﬁrst and foremost legal instruments. They testify the nature and terms agreed between contracting parties. Hence, each contract is primarily bound to the jurisdiction and regulatory law under which it is signed. This legal centric view of a contract cannot be ignored in any contract management methodology. There are efforts ongoing to standardize the regulations on a global basis. Within the European Union, the EC Directives 98 1 have been adopted to facilitate e-commerce. Other organizations like the International Chamber of Commerce have been instrumental in recommending standard models for contract delivery terms (INCOTERMS), etc. Other international collaborative organizations like the United Nations have adopted model contract law (UNCITRAL (United Nations Commission on International Trade And Law n.d.) model law for contracts), or standard product codes like the UNSPSC (United Nations Standard Products and Service Codes Web Resource) or CPV 2. However, law governing trade and commerce may vary from nation to nation. Thus, any business contract that is negotiated must take in to account prevalent local regulations. Within the framework of Information Systems, this implies a need for a translation from technical legalese in to more human or business oriented translation and thereafter machine understandable format representation of the same contractual terms. 1 EC Directives 1998, available online at http://europa.eu.int/comm/enterprise/ newapproach/standardization/harmstds/reflist.html (accessed last on 12-11-2003) 2 Common Procurement Vocabulary: The CPV establishes a single classiﬁcation system for public procurement aimed at standardizing the references used by contracting authorities and entities to describe the subject of procurement contracts. established by the EU SIMAP organization. Details see http://simap.europa.eu/nomen_cod_cpv_what/ 3bc3a032-f9c6-e162-18d2cd794dfeb113_en.html 7.2 Research Issues in Business Contract Knowledge Management 171

Business Process, Commercial Trade Practice and Concept

Every organization has its own in-house business policies and practices. They have certain code and recommended strategies for customer relationship management or their enterprise resource planning or even standard contract terms and conditions. Sometimes, an organization may be flexible and have differential terms with various customers. However, the business workflow would in all probability be the same for all. But, if an organization wishes to maximize its efficiency and profitability then either they should agree to terms that are conforming to their regular workflow pattern or they should be able to adjust their business process flow to be compliant to the contract terms. In other words, business process management cannot remain isolated from business contract management. Legal business contracts govern the business process and the business process influences the actual contract formation. Thus the process centric view of a contract is further strengthened by the business and commercial practice domain. As seen above, the three identified perspectives of the same contract cater to different objectives and needs. At present the boundaries between these identified perspectives are not cohesive and interaction between the perspectives is not easily feasible.

7.2 Research Issues in Business Contract Knowledge Management

Contract knowledge management is a crucial issue in the enterprise management perspective. However, the various approaches deal with the contract in one or more deﬁned perspectives. An integrated, coherent approach for contract knowledge management is needed. Speciﬁcally, legal contract knowledge is isolated from business process knowledge in current information system approaches. Shared common understanding integrating the three perspectives of the contract domain is missing.

1 A research problem, focused in this case study, is to bridge the chasm between legal contracts, business process with respect to current information system requirements. The identified gap needs to be filled in a coherent and meaningful manner that fosters easy shared understanding for both humans and machines. Shared understanding needs to be fostered in a flexible, extensible, simple and reusable form. 2 A secondary problem is that business processes or workflows are designed and executed independently of the contractual expectations. Contracts outline the expected business behavior from the parties involved. Contracts have binding 172 7 Case Study I: The Business Contract Knowledge Management Project

obligations that are to be executed through the performance of business processes. Thus contracts need to be monitored and at the same time they should govern the design of the actual business workﬂow. 3 A third problem is that these contracts are seldom aligned with the internal processes and the way each enterprise actually executes these promised contracts. 4 Another problem is that with business contracts, there are always some associated business risks which if not assessed and countered properly could result in unpleasant situations for the concerned enterprises.

7.3 Objectives for Case Study I

This research aims to solve the problems identiﬁed in section 7.2 through the following objectives:

• To foster reusable shared contract understanding: A contract knowledge modeling approach using current information system methodologies is proposed which would represent an integrated view of business and legal domain. This contract knowledge base would bridge the gap between contracts and business workflows. The proposed contract knowledge model would target human understanding as the primary users. The same should also be machine-understandable and searchable to promote automated processes like contract monitoring, performance monitoring, and contract drafting, etc. - A Multi Tier Contract Ontology framework is proposed to capture the conceptual models of various contracts followed by their translations to machine understandable formats. This MTCO framework follows the multi-tier architecture proposed in the O4IS design methodology. Parts of this work has been published in (Kabilan & Johannesson 2003, Kabilan et al. 2003, Kabilan 2003). - Conceptual models for representing contract knowledge from legal domain are presented with a focus on business contract types. The conceptual models for a typical business sale of goods scenario are presented using the proposed Multi Tier Contract Ontology (MTCO) framework. The conceptual models follow the Dual Representation as proposed in the O4IS, that is UML conceptual models and OWL formal representations. The conceptual models capture the semantics following the semantic concept view in the USP2 design. • To propose business contracts compliant business workflow. A simple, easy- to-understand interpretation of the contractual terms and conditions and their relation to business processes or workflow is also proposed. This phase is an illustration of the procedural concept view of a contract domain. 7.4 Related Research for Business Contracts 173

- We propose a methodology for deducing Contract Workflow Model based on the contract knowledge represented in the MTCO. Contract Workflow Model (CWM) is intended to be a rough outline for recommended business workflow process that would be compliant to the stated contractual terms and conditions. Exemplified detailed methodology is described in (Kabilan 2003). Details of contract workflow model patterns are discussed in (Kabilan 2005). • To align the proposed contract compliant workflow models with the existing internal business process models. In collaboration with another ongoing research, this author has contributed towards the alignment of business contracts with internal business process models. Ongoing work in this context, involves exception handling of processes based on contractual clauses. Details regarding this work is not included in this thesis, but may be referred to in (Zdravkovic & Kabilan 2005b) and (Kabilan et al. 2005). • To propose a mechanism for tracking and measuring contract obligation life cycle: An analysis and representation of the implicit states through which the contract obligations pass through, is proposed as obligatation states. The obligation state classification in itself is an illustration of the pragmatics (deontic) aspects of the business contract being described in the semantics of an ontology. Parts of this work has been introduced in (Kabilan et al. 2003). - A detailed analysis, categorization of contractual obligations on a generic level is included as a part of the conceptual models. This thesis identifies a set of obligation states that are abstract states through which any obligation passes through during the contract obligation fulfilment process. • To propose a method for business contract risk assessment. This author has been part of an IST project INTEROP, wherein, she has worked in a joint research with Weigand, in proposing a methodology and an ontology for business contract risk assessment as shall be discussed later. Details of this work is not included in this thesis but the interested reader is referred to the paper (Kabilan & Weigand 2006).

7.4 Related Research for Business Contracts

The main ﬁelds of related research work from which guidance and inspiration has been drawn may be grouped as:

Contract Management:

Since the research problem and goals deal primarily with contract execution analysis, related work in the realm of electronic contracting as well as traditional contract management form a primary basis for this research. 174 7 Case Study I: The Business Contract Knowledge Management Project

Knowledge Management:

In order to foster shared and reusable understanding, we need to model, capture and reuse the contract knowledge efﬁciently. In this context this research has adopted proposed theories from other related research works in the ﬁeld of knowledge management.

Workﬂow Management:

As stated earlier, the contract defines a set of terms and conditions, which are to be carried out by the parties agreeing to the contract. This research defines a legal business contract to be a legal description of a set of objects (including obligations, prohibitions and rights) that are to be fulfilled by execution of corresponding business behavior on the part of the parties. The proposed CWM methodology derives inspiration from workflow and process flow design methodologies.

Ontologies:

Contract knowledge is proposed to be modeled and represented using Ontology for knowledge representation. As we have already reviewed the Knowledge Manage- ment and Ontologies in our chapter 2 and chapter 3 respectively, we summarize only the background and related research from the other two domains here.

7.5 Contract Management

Contracting encompasses several stages namely conception where parties identify each other, negotiation where offers and counter offers are made, contract establishments which leads to signing and finally workflow execution accompanied by monitoring and fulfilments, as summarized by Angelov (2001). An adapted version also showing the contract knowledge management life-cycle may be seen in figure 7.3. This research focuses on the workflow execution phase of contract knowledge management methodology. We believe that a contract instance is executed through a series of workflow like processes in tandem with business process flows. There are different approaches that have been adopted to analyze, model and represent contracts and their relationship to business workflows. We summarize some of them in the following sections.

7.5.1 Document Centric Approach

Electronic contracting projects like that of COSMOS have proposed architecture and framework for the automated contracting process. Griffel (1998) has described the 7.5 Contract Management 175

Fig. 7.3. Lifecycle of a Business Contract technical foundation for the COSMOS project as based on CORBA and the Business Object Model. They present the Contract Object Model to identify the main component classes of their object model. The COSMOS project identifies who, what, how, legal parts of any contract. The fundamental concepts are similar to the ones proposed in the MTCO. However, in the legal part the approach taken in COSMOS has veered towards a textual document centric analysis. The actual contract has been modeled as a composition of legal paragraphs containing clauses. The primary objective of COSMOS has been to facilitate electronic contracting through all the phases from negotiation using service brokers, contract drafting using component-based contracts. They have used PAMELA (Petri-net based Activity Management Execution Language) to model the contract execution flow model. This research proposes the use of UML (Unified Modeling Language) as knowledge representation language and predominantly focuses on contract execution monitoring and workflow deduction using EPC (Event Process Chains).

7.5.2 Process Centric Approach using Deontic Logic

While COSMOS has taken a document centric view of the contract, Yao-Hua Tan (2000, 1998, 2002) has dealt in detail with directed obligations, permissions involved in trade contracts from a legal and an action (process) centric view. He has used deontic logic to model the notions of permission, rights and obligations. He aims to resolve ambiguity in interpretations of trade relationships by building formal models for the obligations involved. He has viewed obligations as relationships between two agents. He also introduces the concept of bearer and the counter-party agents who are the two roles of the parties involved in the trade contract. He has 176 7 Case Study I: The Business Contract Knowledge Management Project modeled several instances of legal obligations and permissions and their legal implications. However, we find that he has not considered the business domain aspect of a legal contract. The relationship between an obligation and its corresponding performance or non-performance has not been taken in to account in the obligation model. Also, the remedial option for obligation non-fulfilment has been assumed to be that of only legal action, which is not always true in the business domain. Tan has also demonstrated the use of event semantics to model contracts and then used prolog to implement the model. Thus, though we agree with Yao-Hua Tan’s fundamental theories regarding obligations, their types and nature, we differ in our methodology of modeling and monitoring the obligations. We propose a human oriented approach for contract obligation monitoring. Business is always carried out between human counterparts. Business decisions and strategies, however rigid, are always subject to flexibility and change. Thus automated and rigid contract enforcement and monitoring is not a practical solution.

7.5.3 Normative Approach using Subjective and Deontic Logic

In another electronic contracting research, A Daskalopulu (1997)has analyzed contracts for the purpose of establishing contract performance monitoring in (Daskalopulu & Maibaum 2001, Daskalopulu 2002). She has also promoted the legal centric view to a contract. Her work has been focused around automated contract enforcement and monitoring. She has identiﬁed the main issues for contract performance monitoring as (an excerpt from (Daskalopulu & Maibaum 2001)):

• To establish what each party is obliged or permitted or prohibited to do at a given point of time. • To determine whether each party complies with the behavior stipulated in the agreement • When a party deviates from prescribed behavior, to determine what the remedial mechanisms that are applicable, that might return the business exchange to a normal course.

The objectives for establishing the proposed Contract Workflow Model (CWM) in this thesis are similar to those stated above. Daskalopulu also holds the view that software agent aided electronic contract enforcement and performance monitoring is too restrictive for realistic commercial purposes. Thus she proposes a framework for an artificial controller who forms an opinion based on evidence-based reasoning. In this aspect, Daskalopulu uses Subjective Logic to support her proposal. She has used UML state diagram for representing contractual transactions. R We have drawn inferences and guidance from this and other works of Daskalopulu in our ongoing research methodology. We propose a similar obligation 7.5 Contract Management 177 state classification and a transformation in response to the performance of business activities. However, our methodology differs in the manner the research goal is achieved. She has used subjective logic to model obligations and we propose the use of contract ontology (reusable knowledge base) and simple CWM to obtain a similar result. Gangemi, Pisanelli & Steve (2001) have presented a formal ontological framework for representing normative representations specially in the banking sector. Weirenga and Meyer (1993) have provided a concise survey and review of deontic logic based applications in computer science. Amongst them, Jones and Ser- got (1992b) have proposed that at the appropriate level of abstractions – law, computer systems and other organizational structure may be viewed as instances of normative systems. They define ‘norms’ as prescriptive descriptions of how agents ought to behave, and specify their permitted behavior and rights. They go on to argue that deontic logic needs to be considered whenever it is is necessary to make explicit,and to reason about, the distinction between ideality and actuality. Since deontic logic has its origin in the study of law and its ethics, there has been a number of research carried out in the field of applying deontic logic to the legal knowledge representation, as has been surveyed by Sergot (1990). Jones & Sergot (1992a) have also proposed a methodology for legal representation using deontic logic.

7.5.4 Standardization Approach using Courteous Logic Programs

Moving on we find efforts in the current trend for adopting XML as standard business language for information system. Grosof (1999) has proposed Courteous Logic Programs as a declarative approach to model the business rules and policies as expressed in contracts. Grosof has further presented a XML based rule representation language RuleML and has also used it with ontologies to produce SweetDeal (Grosof & Poon 2003), an approach to aid automated creation, evaluation, negotiation and execution of contracts. He has viewed contracts as specification for processes thereby conforming to the process centric view. Business practice (rules and policies) play a major role in his approach for handling contracts. He has dealt with two of the domains, business and information technology, but has not ventured in to the legal aspects of contract. There exist possibilities of integrating other contract ontologies like our proposed MTCO to the system as proposed by Grosof. Thus, the business rule and policies as expressed by RuleML may be interfaced with the MTCO to be able to support the various phases of the contract life cycle (figure 7.3).

7.5.5 Communicative Approach using FLBC

On business process and contract process views, we also find Heuvel and Weigand (2000), who have presented integrated enterprise architecture to integrate contracts with 178 7 Case Study I: The Business Contract Knowledge Management Project business workflow and business objects. They have visualized contracts as the binding glue to cross-organizational business workflows. Contracts are scenarios de- noting sequences of transactions. They introduce a business contract specification language (XLBC) to link to CDL (Component Definition Language) specification of business object based workflows systems. They have based their contract specification language on the Formal Language for Business Communication (FLBC) to specify contracts between enterprises. FLBC catered to EDI standards, and XLBC is an adapted XML version. XLBC architecture is a layered structure from speech acts as an elementary block to workflows and finally contracts, as seen in the figure 7.4 from Heuvel & Weigand (2000).

Fig. 7.4. Multi-leveled Communication Patterns

Contracting using XML based approaches also includes efforts of Goodchild (2000) who analyzes the fundamental concepts for a business contract and models the contract using UML and XML. However, he has viewed the contract as a document and has placed emphasis on the physical characterization of a contract contents.

7.5.6 Enterprise Systems Approach

Milosevic and team have formulated another business domain and contract integration approach. They propose a framework called Business Contract Architecture (Milosevic, Josang, Patton & Dimitrakos 2002). Milosevic (2002) defines a contract as: “Contract is an agreement governing part of the collective behavior of a set of objects it specifies obligations, permissions, and prohibitions of the objects involved, all of which are regarded as constraints on the objects behavior in relation to other object.” In the same paper Genetic Software Engineering method for behavior trees has been used to identify and model components, states, events, decision and constraints 7.5 Contract Management 179 along with causal, logical and temporal dependencies. In Business Contract Archi- tecture, automation of contract activities like drafting, negotiation, monitoring and enforcement has been considered through the use of software agents. Various tools have been designed to handle each aspect. The Contract Form Editor tool is designed to draft contracts and is predominantly a document centric approach to view contracts as textual documents. A Contract Repository is proposed to store all contract instances and a Contract Notary is aimed to monitor and track negotiations. Finally, a Contract Monitor is visualized to monitor the contract execution and monitor performance. As stated earlier, we hold the view that such rigid enforcement agents cannot simulate the necessary and practical commercial aspects when the human counterparts rather than artificial agents plan decisions and strategies. However, this research does agree with Milosevic on the central role played by obligations, permissions and prohibitions in the context of contractual execution monitoring.

7.5.7 Workﬂow Management Approach

Workflow management tools are now being used to support and control business managerial responsibilities. W.M.P van der Aalst has proposed a Petri Net-based approach for modeling workflows in (Aalst 1994, Aalst 1998) as well as formalized the use of event driven process chains for workflow modeling in (Aalst 1999). Our patterns for contract workflow models using BPMN have been based on his workflow patterns work. Karlapalem et al. (2001) has proposed a framework for modeling electronic contracts using a workflow approach. They have used traditional Entity Relationship (ER-R) data model to represent a contract. They present workflow models for task activity model and mapped their contract ER EC model to a workflow specification as:

• Parties from a contract are mapped to agent types and roles in a workflow. • Activities from the contract to workflows are mapped to activities in workflows. • Contracts themselves are mapped to events that occur in the workflow. • Clauses of a contract are mapped to conditions that need to be satisfied in a workflow. • Exceptional handling clauses in a contract are mapped to additional activities in a workflow. • Payments and contracts instances are mapped to physical documents and additional input output events in a workflow.

We see that Karlapalam has adopted a document centric analysis of a contract and mapped them to workﬂow approach methodology. The proposed methodology 180 7 Case Study I: The Business Contract Knowledge Management Project for CWM has been based on above-mentioned workﬂow-based approaches. How- ever, the proposed CWM builds on the reusable shared knowledge base, Multi Tiered Contract Ontology.

7.6 Multi Tiered Contract Ontology

We support Daskalopulu & Sergot (1997) in their identiﬁcation of the following roles of the contractual provisions:

1 Contracts deﬁne terms. 2 Contracts prescribe certain behavior for the parties, under set conditions for a certain period of time. 3 They specify procedure that needs to be followed. For example, the delivery terms inform the buyer regarding the time limit by which he has to inform the seller regarding his transporter, or any change in venue for the delivery, or delivery date. 4 The contracts contain formulae that are used to calculate various parameters, for example, the cost adjustments to price or quantity depending upon ﬂuctuation of currency, changing duties, and tax.

We support and uphold a deﬁnition of a business contract as:

R A contract is an organized collection of concepts, obligations, permissions, entitlements, etc. A contract has also been viewed as a collection of protocols that specify its operational aspects (how the business exchange is to be carried out in reality) or simply parameters (the parties, product, price, delivery quantity, delivery date).

Our proposed MTCO is a combination of all the above mentioned aspects. A layered structure provides the scope for defining individual ontology for specific types yet coherently integrating under one unified framework. The MTCO consists of a set of structured conceptual models represented using UML. From the preceding discussion in our proposed O4IS design methodology (chapter 5), we have established that conceptual models are an abstract form of ontology representation. Thus for the rest of this thesis, all references to the contract ontology layers refer to conceptual models. We now discuss how our O4IS design methodology has been used in this case study.

7.7 Using O4IS Design Methodology and USP2 Design

Above we have seen the issues in business contract management and different approaches to process the information. Our objectives (as stated in section 7.3 have 7.7 Using O4IS Design Methodology and USP2 Design 181 been to: (i) Foster shared common understanding between the different groups of human users of the business contract and (ii) Help in planning, and integration of business contracts with existing business workﬂows, monitoring the fulﬁllment of contracts (iii) Understanding the obligations and their violations as stated in the contract, their possible consequences, remedial options available. Keeping in mind these objectives and requirements of the targeted applications, we design our proposed contract ontology following the O4IS design methodology as described below:

• G1: Establish the scope of domain. The domain is that of business contract knowledge management. As illustrated in figure 7.2, this is an overlap of enterprise modeling, knowledge management and Information Systems and finally the legal system that governs and specifies contracts. In this research, however the process of establishing and negotiating a contract (e-contracting) is not within the scope. Our research is focused on the post-signature, and actual execution phase of the contract life cycle (figure 7.3). • G2: Establish the targeted users, applications, and functional requirements. The primary targeted users are humans: business managers, decision makers, business process modelers, who need to either execute the contract, make decisions regarding possible contract non-compliance, re-design existing internal business process models in accordance with the contract and so on. As such the functional requirements is that the ontology should be clear, precise and consistent. It should be comprehensible to the non-information system experts as well. It should be reusable, shared across different organizations, and systems, etc. • G3: Choose ontology architecture: physical and logical. The physical architecture chosen is that of a single local ontology for the moment. This is abstract research and hence we have not tested it in real time applications where a distributed architecture may be needed. The logical architecture followed is the multi tier architecture proposed by the O4IS design methodology. • G4: Choose ontology development approach. We adopt a middle out approach. We begin our study and analysis from specific contract models and thereafter, study the governing rules, laws and models like the UNCITRAL that are generic across many types of contracts. • G5: Choose level of ontology representation. As our primary targeted users are humans we have mainly used conceptual models as our representation language. We have adopted ODM specification for OWL formalization, and implemented them as stereotypes in UML meta model. Therefore, our conceptual models are conforming to ODM recommendations and can be translated in to OWL. In this case study, we have not carried out extensive implementation in OWL formalizations. • G6: Choose knowledge acquisition methods and tools. This case study was the first iteration for this O4IS design methodology and hence we have not used 182 7 Case Study I: The Business Contract Knowledge Management Project

any specific knowledge acquisition tools. Our work has been based on extensive literature study and study of other contract related research. We have also had input from lawyers in the initial stages of knowledge gathering. After gaining sufficient domain knowledge we have carried out the analysis and conceptualization following an iterative method of abstraction and specification. • G7: Knowledge analysis- Conceptualize the domain ontology. As stated, our main interest in this case study was to make domain assumptions explicit and to analyze the fulfillment or state changes of contractual obligations. Hence, our main work has been on the Semantic Concept View extraction. We have analyzed the deontic aspects of the contract, namely the obligations and proposed a set of obligation states. This is the pragmatic concept view which has been declaratively included into the semantic concept view itself. The Procedural Concept View in this case study needs to make explicit the expected behavior of two parties involved in a contract execution. This is similar to modeling a dialog between two actors, whose responses can be expected but not predicted. Therefore, we propose a domain specific methodology called the Contract Workflow Methodology to deduce the contract compliant business workflow model. • G8: Knowledge representation: Implement the domain ontology. The Seman- tic and Pragmatic Concept View are represented using UML conceptual models. The Procedural Concept View following the CWM methodology has been represented using EPC diagrams as well as BPMN. We have further proposed CWM- BPMN patterns to ease the analysis and design part for information system designers. • G9: Evaluate, assess and verify the domain ontology. The evaluation and assessment for this case study has been done following the design science research methodology. The actual ontologies have only a theoretical assessment. In future projects we hope to be able to implement in real applications to verify the accuracy of the models. However, the conceptual models being based on standard contract documents and recommendations are correct to the best of our knowledge. Having said that this author is not a legal expert and thus there could be subjective errors due to misinterpretation. • G10: Use, maintain and manage the domain ontology. So far we have worked through two iterations of the development for the proposed MTCO. We refined the structure of the ontology based on the feedback and review we got after the dissemination of research through scientific communication. We have also semantically enriched the second version of the ontology, now implemented in Protégé by annotation with Wordnet.

After the overview of how we have applied the proposed O4IS design methodology and the USP2 Design, we now describe the proposed ontology. 7.8 Multi Tier Contract Ontology: Semantic Concept View 183

7.8 Multi Tier Contract Ontology: Semantic Concept View

The MTCO is envisioned to consist of the following layers (illustrated in ﬁgure 7.5 below):

Fig. 7.5. Multi Tiered Contract Ontology

• Upper Level Core Contract Ontology: Represents a general composition of a contract, which may be applicable across most of the prevalent types of contracts. The concepts defined here may be considered to be atomic blocks based on which all other contract types may be defined. Fundamental concepts like role, consideration, and obligation are defined here. • Specific Domain Level Contract Ontology: Contract type specific collection of several contract type ontologies. Each ontology represents a specific contract type, such as Property Lease Rental, Employment Contract, and Sale of Goods, etc. Each contract type inherits all fundamental features of the upper layer and thus specializes on the knowledge particular to that contract domain. • Template Level Contract Ontology: Consists of a collection of templates such as definitions for contract models, such as the International Chamber of Commerces contract model for International Sale of Goods.

The Upper Level Core Contract Ontology defines all the required and necessary components of a business contract in order to be legally valid. For electronic contracts, we would have additional concepts like digital signatures, public key encryp- tion, security and archiving issues. This Upper Level Core Contract Ontology should capture all the common concepts under one umbrella. The objective is to define fundamental concepts like actor, role, and consideration in a generic manner that 184 7 Case Study I: The Business Contract Knowledge Management Project would be applicable to any business contract, keeping in mind that the scope of our research problem as limited to the realm of business contracts. The second, Specific Domain Level Contract Ontology relates to specific contract types. Some examples of business contract types include purchase of good, services, hire and lease rental contracts, employment contracts, business trade partnership contract, and real estate property, etc. Each of the contract types may be designed and represented as an individual ontology. Each of the specific contract type ontology would define the major concepts particular to that contract type and would specialize and extend the definitions inherited from the Upper Level Core Contract Ontol- ogy. As an illustration, we propose a specific contract type ontology specification for Buy-Sell of commercial goods. In this respect, we draw conclusions and guidance from various internationally adopted legal directives like UNCISG (Nations 1980), UNIDROIT (UNIDROIT principles of International Commercial Contract, 1994 1994) principles for commercial transactions, and UNCITRAL (United Nations Commission on International Trade And Law n.d.) model contract law, etc. The research has been focused specially on the obligations and the expected fulfilment through the execution of performance events. This has been done in order to facilitate easy integration and understanding of the required business process workflow to comply with the contract terms. The third layer, Template Level Ontology is visualized as a group of pre-defined contract models that could be readily instantiated. These incorporate standard recommended contract forms like that of ICC’s 3 contract model form for International Sale of Perishable Commercial Goods (books 2002), or standard forms for sale of used vehicles. Each pertains to the same contract type but yet differ in specific information details contained within them. Each of the template contract ontology would essentially inherit from specific contract type ontology. In this level the concepts are further narrowed down and specialized even to the level of defining Meta-data specifications and constraints. This framework allows the MTCO to be flexible, extensible and coherent. It can be easily extended horizontally and further layers are also possible. Moreover, users of the ontology can extract and use parts of the ontology as required for their domain of applicability. MTCO is a hierarchy of ontologies moving from the general to the specific and then down to precise Meta-data definitions.

7.9 Upper Level Core Contract Ontology

In this section, we present the Upper Level Core Contract Ontology in detail. We start with an illustrative case scenario to help identify the principal concepts involved.

3 International Chamber of Commerce, http://www.iccwbo.org/ 7.9 Upper Level Core Contract Ontology 185

There after we present a detailed conceptual model for this layer. A discussion on the major concepts follows the conceptual model.

7.9.1 Basic Concepts

For sake of simplicity and ease of understanding we present the high level concepts in figure 7.6, followed by detailed conceptual models as extracts in the following figures, figure 7.7 to figure 7.12. Note that they together comprise the Upper Level Core Contract Ontology . The current versions of the conceptual model are targeted for human to human knowledge transfer and understanding. Hence details and constraints for machine querying and understanding are not included at present. We

Fig. 7.6. Upper Level Core Contract Ontology: Overview

explain the main concepts identified in figure 7.6 with the help of a hypothetical case scenario where a person (seller) promises to sell cars to another person (buyer) in return for some amount of money. A promise is a statement of commitment or obligation to fulfil some act or perform certain deeds. When a promise is made with the legal intent to back it up in any court, it becomes a legal obligation or commitment. Cars are the object or consideration of the Promise: a consideration is any material or abstract benefit or thing of value for the exchange of which two parties agree to enter in to a contract. It could also be simply a promise to fix a leaky roof or a promise not to do something. ‘Selling’ becomes the performance, which fulfils the above promise. The promise to sell is an obligation which is realized only when the 186 7 Case Study I: The Business Contract Knowledge Management Project actual business act of giving the cars in return for the money is performed. An obligation must have a Claimant or a Beneficiary of the obligation, that is one who receives the consideration or is the recipient for whom the promised act is being performed or carried out (called the obligation owner). The buyer who buys the cars and pays money for it is the Receiver of the obligation to sell. The contract outlines the terms and conditions under which the promised performance shall occur. As seen in figure 7.7 we have other concepts like obligations, prohibitions, rights, warranties. In a normal situation, a contract is executed as planned and agreed. In case the expected performance does not occur within the expected time frame or occurs in an unsatisfactory manner or is delayed due to forces beyond the control of the promisor, then the primary obligation goes in to a state of ‘Unfulfilment’. The occurrence of the non-performance event activates certain pre-agreed rights on behalf of the promisee. In this case, the buyer may have the right to seek remedy in the form of some interest or penalty, or may choose to terminate in accordance with the agreement. But the buyer may also choose not to do anything and could settle the issue by mutual agreement. However, irrespective of whichever course of action the buyer chooses, the seller (the promisor of the primary obligation) is bound to accept the choice and is now bound in a reconciliatory promise to fulfil the remedy requested. This secondary or reconciliatory promise may also include the fulfillments of the initial primary promise to sell. We have seen a simple case scenario where the actors have defined responsibilities or roles; agree to perform certain acts as per agreed terms and conditions in a mutually satisfying and acceptable manner. We further see that the contractual terms and conditions bind the actors to various obligations which maybe legal, ethical, business or a combination of any of the types. Obligations may give rise to other obligations and rights. Actors are also empowered by certain other rights or may be bound by other prohibitions too. Rights too may give rise to new obligations. There is a complex interplay in between obligations, their performance or non-performance, probable secondary rights and obligations. R This implicit as well as explicit knowledge embedded in a business contract is the focus for the Upper Level Core Contract Ontology. The Upper Level Core Contract Ontology is not a mere catalogue of identified concepts, classes or definitions. But it emphasizes on the implicit and tacit understanding of fundamental contractual concepts like obligations, performance and non-performance. The deontics involved in this social domain is analysed and represented through obligation state models. This is crucial from the business process integration perspective since one needs to be aware of the implications of contractual obligations and repercussions while making business related strategic decisions and choices. 7.9 Upper Level Core Contract Ontology 187 Upper Level Core Contract Ontology: A detailed Semantic Concept View Fig. 7.7. 188 7 Case Study I: The Business Contract Knowledge Management Project

For a detailed description of the above mentioned concepts we refer the reader to (Kabilan 2003). In the following section, discuss our analysis of obligations, obligation types and obligation states.

7.9.2 Contract Obligation Analysis: Pragmatic Concepts Analyzed

Obligations or Commitments (as they are also known as) are not only legal bind- ings but also are also business, moral and ethical related too. A business contract is drawn up with the primary objective of clearly defining the obligations that all the parties to the contract undertake to perform. Along with that they also agree upon the method or manner in which the promised performance is supposed to occur. It is to be noted that the business contract lays out the boundaries and parameters for the expected behavior, which should govern the actual business execution. In other words, a contract compliant business workflow execution should be modeled based on the agreed upon contractual behavior pattern. This is the fundamental assumption on which this thesis builds. Therefore, we analyze the concepts of obligations and their related performance more closely than other concepts illustrated above. A clear understanding of what an obligation implies and what is necessary to fulfil the obligation is paramount from the business process modeling perspective. As mentioned earlier, obligations may be categorized in to different types. An individual obligation may belong to more than one category. The following obligation categories or obligation types are based on the nature of obligation fulfilment required or on the nature of implications of the obligations. Obligations have been the subject of discussion for several other researchers.

7.9.3 Obligation Types

As proposed by others like Ronald Lee (1988), Yao-Hua Tan (1998) and Daskalop- ulu (1997), we acknowledge that the statements in a legal contract are either informative or declarative (also called as performative statements by some). Informative statements pertain to the description of the actors, the subject of the contract, jurisdiction and other pertinent information. Declarative or performative statements are statements of intentions or conditions, whose execution undergoes state transformations. This thesis focuses on these declarative statements that are in fact a statement of intent and describe the choreography of expected behavior from the parties involved. Declarative statements include rights and prohibitions in addition to obligations. A brief recap of the concepts of obligations, rights and prohibitions as described in the preceding section: • Obligations: Obligations are mandatory. They have an Obligee and an obligor. Obligee has to be mandatory executed the obligation condition once and only once in every single execution of the contract. 7.9 Upper Level Core Contract Ontology 189

• Permissions/Rights: Permissions or Rights have only a rights Owner. The execution of a right is of an optional nature or it may be conditional depending on the execution of some other obligation. • Prohibitions: Prohibitions are statements of whatever actions should not be executed or whatever actions may be unacceptable to either or both parties.

These declarative statements are bound to their performative actions or non- performative actions for their fulﬁllment.

Fig. 7.8. Performance Event Types

As seen from figure 7.8, performance event types may be of business acts, legal acts or moral acts. In cases it may even be a combination of one or more of the performance event types. Every obligation is fulfilled by the related performance event. For ease of understanding, we identify the obligations to be of business, legal or moral obligation type. However, all obligations are legally binding in any case. This obligation type classification is more abstract and intended for the purpose of understanding than for any other legal or business purpose. We describe the basic obligation types as shown in figure 7.9 as below:

• Business Obligation Type: We state that business obligation type require some related business activity or process to occur for the obligation to be fulﬁlled. For example, in case of the obligation to deliver, the seller must initiate the business process of procuring or manufacturing the product to be delivered, etc. Business obligations can be further sub grouped as being monetary business obligations or non-monetary business obligations. Certain business activities are essentially ‘economic acts’ as deﬁned by REA ontology (Geerts & McCarthy 2000). That is, 190 7 Case Study I: The Business Contract Knowledge Management Project

Fig. 7.9. Business Contract Obligation Types

there is a certain monetary value attached to the event fulfillment. Others like the act of informing the seller of the chosen carrier or the required packaging can be classified as non-monetary business obligation. • Legal Obligation Type: Legal obligation may be fulfilled by some legal acts like signing the contract or sending an acknowledgement receipt, or notification of delivery, etc. Understandably these are in any case performance acts and could be a part of normal business acts. • Moral Obligation Type: Moral obligation may be based on common business trade customs or understanding like aiding the other party in customs clearance or advising of local practices etc.

The above grouping schema for obligations aids us to further analyze the precise nature and relationships between obligations and performances. This is a crucial step in our analysis as this forms the base for the transformation of the contractual semantics from objects to contractual process flows. Based on the nature of their fulfilment execution, we propose a categorization of obligations in to the following abstract categories, for ease of grouping and understanding, refer figure 7.9:

• Primary obligation: Has to be fulﬁlled whenever the contract is to be executed and is the principal objective behind the agreement itself. Like the obligation of a seller to deliver goods in conformity to the contract or that of a buyer to accept and pay for goods as ordered. • Reciprocal obligation: Could be a primary obligation in itself, but is also the obligation expected to be fulﬁlled by the counter party in response to the execution of the primary obligation. E.g. the buyer’s obligation to pay is reciprocal to 7.9 Upper Level Core Contract Ontology 191

the seller’s obligation to deliver and vice versa. Also the buyer’s obligation to pay is a primary obligation for the buyer. • Conditional obligation: Does not need to be activated under the normal course of events. Most remedial rights and obligations come in this category, like the buyer’s right to seek compensation for failed delivery, binds the seller to deliver the goods at his added cost. • Secondary obligation: Gets activated as a part of some other obligation. Like the sellers obligation to package goods suitable for transportation could be said to be sub unit of his primary obligation to deliver.

In the next section we move on to the life cycle of an obligation and the phases or states through which any obligation may pass through. Our analysis of obligation state changes is similar to the state change semantic relationships that Storey (2004) has proposed.

7.9.4 Business Contract Obligation States

At the time of signing the business contract all the agreed upon obligations become legally valid and binding. From a legal perspective the contract obligations are activated and they remain active through out the contract period, viz, the duration from and till which the contract is deemed to be valid. However, from the business and contract execution perspective, once the contract is signed, we assume the plan to be set in motion, but the actual execution is subject to the business process execution and has to be synchronized with the business process flow. Hence, we propose an analysis and states of the obligation life cycle in tandem with the business process activity state transitions and executions. An obligation may be said to pass through some abstract ‘Obligation States’ in response to some business activity or related business state change events. The identification of these obligation states and their relation to business process or workflow allows us to identify points of integration between business contracts and existing business process workflow. Another advantage of the obligation state classification is that it is now possible to monitor and track the contractual obligations as they are being executed. This in turn enables us to also monitor the overall contract compliance and business performance efficiency. An overview of the proposed obligation states can be seen in (figure 7.10 and figure 7.11) and they are summarized below:

• Inactive: Every obligation can be said to be in an ‘inactive’ state once the contract has been signed but contract execution is yet to be started. The obligation will remain in ‘inactive’ state in between cycles of contract execution also. • Active: An obligation may be said to be ‘active’ when the triggering performance event has been issued. For example, once the buyer sends the Purchase Order to the seller and he receives it, then the seller’s obligation to deliver is triggered. 192 7 Case Study I: The Business Contract Knowledge Management Project

Fig. 7.10. Business Contract Obligation States: Overview

• Pending: When fulfilment activity from performer’s side has been accomplished but the acceptance from the other party is still awaited. When the seller has dispatched the goods from his warehouse, and is waiting for the third party carrier to deliver the goods to the buyer. Alternatively, an obligation may remain in the pending state, till the all the necessary fulfilment criteria are satisfied. The buyer may have received the goods but may have rejected the goods as being unsatisfactory. • Fulfilled: When the performance conditions are satisfied within the stipulated performance conditions. Once the buyer inspects the goods and accepts the delivery. • Terminated/Cancelled: If the activation of the obligation is terminated or canceled by the Obligee, mutually, or legal authority.

Such executions of obligation in different scenarios are modeled to form a basis for the classification of obligation and their fulfilment options. The identification and demarcation of these obligation states is the key to monitoring and tracking the execution of the contract. When the seller and the buyer sign a contract, all obligations are stated but they are inactive (refer figure 7.11) and on the occurrence of the performance event ‘receive order’ the state moves into the next obligation state. In figure 7.12 we see an illustration of a typical lifecycle of a seller’s obligation to deliver. When the buyer sends an actual order for the goods to be delivered and the seller acknowledges the order receipt, the seller’s obligation to deliver is activated. 7.9 Upper Level Core Contract Ontology 193 Business Contract Obligation States: Detail Fig. 7.11. - 194 7 Case Study I: The Business Contract Knowledge Management Project

When the seller dispatches the goods for delivery, the obligation may move in to a state of being triggered. Once the delivery is accepted as being satisfactory or within the acceptable tolerance level the obligation to deliver can be accepted as fulfilled. This activates the buyer’s obligation to pay. In case of non-performance, like delay or unsatisfactory delivery or failure, the obligation goes in to a state of being pending. There are several recourses possible hereon. The buyer’s rights to remedy are activated and may choose enforcement options. The buyer may opt for a penalty and accept delivery at a later date, or he may choose to accept the delivery without any further penalty or he may choose to terminate that order or the contract itself. In case the buyer seeks some compensation, it will activate the reconciliatory obligation on the seller’s behalf and that obligation goes through its life cycle. Provided the penalty compensation is successfully fulfilled, and then the initial pending obligation will get fulfilled. In the worst scenario, when the order or the contract is terminated, the obligation itself is terminated. Such executions of obligation in different scenarios are modeled to form a basis for the classification of obligation and their fulfilment options. The identification and demarcation of these obligation states is the key to monitoring and tracking the execution of the contract. When the seller and the buyer sign a contract, all obligations are stated but they are inactive (refer figure 7.12). R We see that here we are dealing with the contractual domain pragmatics. Our analysis of contract obligation through its various state changes is similar to Storey’s analysis of state-changes as discussed earlier. Thus, our proposed contract obligation state models are, in themselves, a conceptual modeling pattern, for the business contract domain. Fig. 7.12. Typical Contract Obligation Life Cycle 196 7 Case Study I: The Business Contract Knowledge Management Project

7.10 Speciﬁc Domain Level Contract Ontology

The second layer in our proposed MTCO, is a collection of contract types. The focus in this research has been primarily on business contract types. Business contract types cover a wide range of applicability, usage and legal contractual obligation types like sales contract, service contract, bill of sale, transfer of technology, procurement, licensing. We also propose to map to other existing ontologies like product catalogues (UNSPSC (United Nations Standard Products and Service Codes Web Resource), payment terms (standard payment methods), and delivery terms (ex IN- COTERMS), which can be applicable across diverse contract types. Specific Domain Level Contract ontology provides information for users trying to understand the obligations, rights and their fulfilments conditions and exceptions particular to that specific contract type. Each contract type is an extension or restriction of the upper level core contract ontology to a specified domain. We present conceptual models for sale of goods contract in this thesis. In a sale of goods contract, (see figure 7.13) the principle role players are commonly called as seller and buyer. The role domain is restricted to that of selling and buying. Either the seller or the buyer may initiate the contracting process and thus may be the proposer or the acceptor. The consideration (refer figure 7.13) is usually some real world entity or goods (both perishable, non perishable), but generally of a quantifiable and measurable entity. The business transaction involved is that of an exchange of resources of value in between the two business partners. So the main performance events are that of delivery (non monetary) and payment (monetary). A seller would necessarily have to bind himself to a promise to deliver as per the agreed delivery terms. Now delivery terms may refer to standards like IN- COTERMS or may simply define the agreed conditions. The delivery conditions may be interpreted as business practice constraints in the business process view. Similarly, the buyer has to commit to pay for the goods received as per the payment terms agreed. Its possible to include recommended payment standards as the Unified customs and Practice for Documentary Credits as modeled by Lee (1988, 1998) within this sales of good domain ontology. In figure 7.13, some sample business activities have been included as shaded concepts to explain the expected performance events more explicitly. Typically a legal business contract may or may not include such explicit references. But an indicative inference may always be included. For example, obligation to pay is unfulfilled if there is an occurrence of late payment, partial payment on behalf of the buyer. Another example as illustrated in the figure 7.13 is that the seller has a conditional obligation which is activated when the buyer invokes his right to cancel. In this case, the seller’s conditional 7.10 Specific Domain Level Contract Ontology 197 - Extract from Sale of Goods Contract showing expanded view for Buyer’s Obligation to Pay Fig. 7.13. 198 7 Case Study I: The Business Contract Knowledge Management Project obligation is fulfilled when he accepts the cancelation and performs the actions of cancel shipment and/or cancel delivery as the case may be. It is to be noted that the above is only an extract from the entire analysis of ICC’s sale of goods contract model. Similarly, delivery terms are also negotiated and expressed in a contract. The delivery terms include details regarding the time, venue and choice of place of delivery. Standard delivery terms like International Chamber of Commerce’s INCOTERMS (Ramberg 1999) can be used to describe the delivery terms. We see that such terms and conditions, either explicitly or implicitly, defines some legal or business commitments on the part of the parties concerned. These commitments that bind a role player, like the buyer or the seller, to perform certain acts are called as obligations. The primary obligations of a buyer are obligation to pay and an obligation to accept goods as inferred from INCOTERMS. On the other hand, a seller is bound by the obligation to deliver and an obligation to accept payment as his primary obligation. Obligations need to be fullfilledBy the execution of expected performance. Say for example, a seller’s obligation to deliver could be accepted as fulfilled only if he carries out the business activities that can be termed as a delivery. The actual performance of delivery would probably be comprised of several other business activities, which have been shown as shaded concepts in figure 7.14. Such information, presented in the conceptual models of the sale of goods specific domain ontology, forms a useful contribution towards generating the CWMs for the business entities. It also helps in business process integration by identifying and ex- posing shared business activities as possible points of business interoperability and interfaces. In the extract shown (figure 7.14), we see that the seller’s obligation to deliver is fulfilled by delivery. In reality, it is quite possible that execution of a promised event is not always successful. A contract generally provides alternatives for handling such exceptions and unacceptable non-performances (See details in figure 7.15). For example, the obligation to deliver may be UnfullfilledBy if the delivery is late or delivery is not affected or the delivery is made, but the goods do not conform to the specification as described by the goods specification. In such cases, the buyer gets the right to seek redress for the failed performance. The buyer may be presented with one or more enforcement options, whereby he could make a choice from the available options, like choosing to have the order canceled or simply imposing a penalty or opting for a re-delivery of the goods or even having the contract it terminated. The buyer’s choice then binds the defaulter, the seller to a reconciliatory obligation to fulfil the chosen form of remedy. The seller has a secondary obligation to package the goods he delivers. 7.10 Specific Domain Level Contract Ontology 199 - Extract from a Seller’s Obligation to Deliver and its Fullfillment/Unfullfillment Fig. 7.14. 200 7 Case Study I: The Business Contract Knowledge Management Project i.7.15. Fig. biaint eie n eae Rights Related and Deliver to Obligation - 7.11 Template Level Contract Ontology 201

R A detailed analysis has been done for each kind of obligation, rights, or prohibitions that can be included in a typical sale of goods contract. Thus a wide range of possible scenarios involved in a commercial business transaction is covered. This forms an essential knowledge base for the business decision, and strategic planning also. Awareness of possible consequences of non-performance or non-compliance to a contract terms could inﬂuence the business process management to a great extent. Contract compliance and performance monitoring have been a crucial concern for most business managements. MTCO is visualized to contribute towards business knowledge management, improving efﬁciency and performance. On a wider horizon, the proposed ontology framework is visualized as a global network of integrated knowledge resources, exploiting the vast potential of the Semantic Web to its utmost. An analysis and models for the INCOTERMS is included in the appendix A.4.

7.11 Template Level Contract Ontology

The third and final layer is a conceptual model of standard contract models and is application oriented. The templates provided here are intended to act as a guide to understand the contract templates while drafting contracts. The template layer ontologies further narrow down the scope and range of each contract type, finally arriving at a specific domain and interest specialized contract form. Say for example, a Sale of Automobile Contract template (figure 7.16) requires the consideration, the Motor Vehicle, to define specific characteristics such as make, year of manufacture, vehicle registration number, and engine chassis number. Another nearly similar contract template could be of sale of boats (figure 7.17). The major difference is the specification of the consideration. There are some vari- ations in the nature and scope of the obligations involved. The template ontologies being so specialized have little or no reusability outside their specified range of use. R So far we have seen how we have captured the implicit and explicit vocabulary of the contracts in the Semantic Concept View. It is to be noted that with our obligation state analysis we have actually captured part of the implicit domain pragmatics as part of our declarative Semantic Concept View. In the next section, we see the Procedural Concept View for our contract case study. As said, here instead of UML class diagrams as the final representation we have opted for other workflow notations like Event Process Chain diagrams and BPMN (Business Process Modeling Notation). BPMN can be translated in to executable (machine readable) BPEL (Business Process Execution Language). 202 7 Case Study I: The Business Contract Knowledge Management Project

Fig. 7.16. Sample Template Level Contract Ontology Model for Sale of Motor Vehicle

Fig. 7.17. Sample Template Level Contract Ontology Model for Sale of Boats 7.12 Deducing Contract Workﬂow Model: The Procedural Concept View 203

7.12 Deducing Contract Workﬂow Model: The Procedural Concept View

A typical business sale contract between two different business organizations contains data important to the business process transactions like delivery date or shipping address or payment currency. The data put together, provide information regarding the procedures to be followed for delivery or payment. Information regarding expected delivery procedure and the possible repercussions of deviations provide the business enterprise with knowledge of their contractual obligations, and the expected fulfillment patterns. This in turn influences the business management to take appropriate steps in the actual execution of the business process so as to comply with their obligations. The performance of the business process provides the data (like actual delivery date, or actual shipment date or payment received date), which is used to compare and monitor the compliance of the executed performance with the stipulated information or contractual obligations. The MTCO models explicit, declarative and strategic knowledge contained within a contract. Interdependencies and relationships between the components of a contract are represented. The three-tier contract ontology is a stratified presentation of information, moving from the most generic upper level core contract ontology domain to the specific domain level contract ontology domain and further down to implementation specific template level contract ontology. The MTCO has been presented by us in section 7.6. The procedural knowledge and strategic knowledge is presented through the choreography of obligations and performance events in the contract, is then modeled as a set of Contract Workflow Models (CWM). In section 7.9.3 and 7.10, we have presented a detailed discussion on our analysis of the obligations and a classification of the different obligation states has been presented. The actual business workflow should be as close and similar to the deduced CWM to be compliant with the contract conditions.

7.12.1 Contract Workﬂow Model

Increasing use of ontological engineering in the realm of business process engineering has been supported by Deborah McGuinness (2000) who identiﬁes the goals for ontological development and proposes guidelines for a centralized knowledge base to capture semantics from domain, standard terms and vocabularies. Howard Smith (2003b) states,

“Agent based system rely upon ontologies to provide a map or blue print of the space each agent navigates through communication and interoperation with other agents.” 204 7 Case Study I: The Business Contract Knowledge Management Project

Howard Smith also emphasizes on the need for software engineering, business process re engineering and ontological engineering integration. We model obligation states to capture the information relevant to that obligation as the fulfillment is being executed. Relationship between obligations, obligation states and performance events forms the foundation for the proposed CWM methodology. We visualize a contract as containing prescriptive directions for the execution of business activities or tasks that will in turn fulfill the obligations expressed in the contract. We now propose a methodology for deriving the Contract Workflow Model (CWM) from any given business contract instance, using a contract ontology knowledge base, the Multi-Tier Contract Ontology (MTCO). We follow the same pattern- based description adopted in this research to describe the CWM methodology as stepwise guidelines for any user aiming to derive the CWM from their signed contract. The user makes use of the available MTCO as a reference to help him easily understand and pinpoint the obligations and the expected performance for fulfilling the legal obligations. The CWM is the first step in ensuring interoperability between enterprises. This paper makes use of BPMN (White 2004) for representing the CWM. We have presented a set of BPMN patterns for common CWM in (Kabilan 2005), we include some of those patterns to exemplify our work in section 7.12.5. Thus, the CWM may be translated into executable BPEL4WS or mapped to other business process specifications like BPSS(Business Process Specification Schema). Hence, the identification of the common points for communication, activating performance events and the chorography of obligation fulfillment, is a fundamental step towards affecting full interoperability. We define a CWM as:

R A partial choreography of performance events for each of the parties concerned as deduced from the perspective of the governing business contract and is an indicative model for the contract compliant business process model.

Following this, below we outline the procedure for obtaining a CWM from a contract:

- The contract document is analyzed to extract the data contained in it. - The extracted data are compared and matched to the specified meta-data concepts as established in the Multi Tier Contract Ontology. The two steps are re- peated iteratively to obtain all the concepts and their instances in the contract. - From the identified contract type ontology, the common obligations and their performances, defined or suggested, are considered. Added to the specific information from the contract instance, the list of all stipulated obligations and the required or inferred performance events is obtained. 7.12 Deducing Contract Workflow Model: The Procedural Concept View 205

7.12.2 CWM Methodology

We now discuss the CWM methodology in detail. The Information Systems designer needs to have as input, the agreed contract, any details of the existing business process model (optional), the proposed MTCO as a lexicon. We ﬁrst give an overview of the different phases and thereafter elaborate with the help of a typical business contract example.

• Phase 1: Contract Type Identification: The first phase enables the user to identify the contract type to which the particular contract instance belongs. This is done by guiding the user to identify the principal components from the upper level core contract ontology and then moving on to match the specifics to specific domain level contract ontology. • Phase 2: Contract Instance Meta-data Extraction: Once the user identifies the specific contract type to which the contract belongs to, he identifies all the major object components of the contract type with respect to the contract instance given. This leads to the identification of pertinent Meta-data and information available in the contract instance. At the end of phase 2 the user should be able to draw an object diagram for his contract if so desired but not absolutely necessary. It would suffice for the novice user to come up with the list of identified objects and Meta-data. • Phase 3: Obligation, Performance Events Identification: Identify the process oriented obligations, performance events, non-performance events, rights objects from the identified list of objects/Meta-data. • Phase 4: Obligation, Performance, Non-Performance Inter-relationships and Conditions: Identify the conditions, pre conditions and binding relationships between each of the identified obligations, rights, performances and non-performances. Also identify the different obligation types, the various obligation states through which each obligation may pass through and their related performance event or right as the case maybe. Finally, to arrange the identified obligation states and the performance events in a time ordered sequence list. • Phase 5: Mapping to existing Business Process Workflows: In case, a business process or business workflow is available, a semantic mapping between the contractual performance events and the available business process flow is executed. • Phase 6: Logical sequencing of Contract Workflow: In this phase, the user is guided to sketch a rough activity-state flow chart to help him visualize the expected choreography of contract obligation execution workflow. The user may use any notation for sketching the activity flow diagram. The performance events which respond to or change each of the obligations to the fulfilled state, are the identified points for business process interoperability. UML activity -state dia- 206 7 Case Study I: The Business Contract Knowledge Management Project

grams or any other notations like EPC (event driven process chain) notation may be used. In this paper, event driven process chain (EPC) notation has been used. • Phase 7: Deducing the ﬁnal Contract Workﬂow Model: Now, the user, takes only the performance events in the sequence in which they occur along with the obligations from each of the two individual diagrams for the obligation- performance event (from the previous phase). Using BPMN notations, the user is required to represent the performance events as tasks, and the individual obligation-performance diagram as two business processes, using swimlanes. In case of secondary obligation, all the related activities may be modeled as sub processes using the BPMN. A detailed discussion on the mapping to the BPMN is discussed in the section 7.12.5.

However, the user may use any notation for sketching the final CWM as discussed in the last phase. We present two possible representations, namely BPMN and EPC diagrams. The objective is to emphasize that the conceptualization of domain knowledge is independent of the representation language chosen, as we have discussed continuously in this research. The proposed CWM methodology holds good irrespective of the representation language. All that is required is a mapping between the representation language syntax (notations) and the concepts identified in the CWM. We now take up the Event Driven Process Chain diagrams (EPC) as representation language, we discuss BPMN in the next section. The EPC makes use of logical connectors AND, OR and XOR to channel the flow of event execution. Performance events are represented by events and obligation state transitions are represented by functions in the Event-Driven Process Chain diagram. If required the user may also transform the deduced CWM in to formal Petri-nets. Aalst has proposed formal methodology for transforming EPC notations to formal Petri-nets in (Aalst 1994).

7.12.3 Detailed CWM Methodology

Once again, we follow a pattern for describing each phase as: Name: The phase number and descriptive name for the phase is included. Input: Expected input sources and material is listed. Output: Expected output at the end of the described phase. Tips: In case there are some additional recommendations and tips for the designer. Process: Describes in a series of steps, what the designer has actually got to do. Step: Procedure to be followed at each step Note,that the name of the phase is included below as the subsection heading itself. 7.12 Deducing Contract Workﬂow Model: The Procedural Concept View 207

Phase 1: Contract Type Identiﬁcation

Input: Contract Document, MTCO. Output:Contract document, identiﬁed shared domain ontology or template ontology. Process: Step 1: Go through the contract to identify the contract type, like sale of commercial goods, lease rental, non disclosure agreement, and service level agreement. Tips: In most cases the contract type would be explicitly stated as part of the heading or covering information. It is necessary to have the legal intent and scope stated explicitly in a contract. Step 2:

• Search and compare with available template ontology to see if the contract is based on any pre-deﬁned form. • If not, then the user should be able to locate the shared domain ontology speciﬁc to the contract type, like Sale of Goods Ontology for buy-sell contract type. • If no contract type ontology is found, then the user has to make use of the Upper Level Core Contract Ontology to identify all the concepts, as described in Phase 2 below.

Tips and Discussion: If the contract is based on template ontology, then all the user has to do is to extract the actual data information for each of the Meta-data components as stated in the template ontology.

• If it is based on a shared ontology, then the user still gets to identify the actual information. Roles, obligations and performances stated in the shared ontology would necessarily be there in the contract instance. Like from the Buy-Sell contract model ontology, he gets the main concepts like that the primary role players are the seller and the buyer. Their primary obligation is to deliver goods and pay respectively. Other attributes and associations indicated present the user with a set of information, which he needs to search for in his current instance of the contract. Additionally, he has to check for the contract speciﬁc performance conditions and statements, as the parties may have agreed upon some other conditions over and above the recommended minimum conditions. The user can use the Upper Level Core Contract Ontology to further enhance his basic understanding of the contract concepts and iterate till he can identify the entire stated obligation, performance, rights and other conditions. • If no shared ontology can be found, then the user has to start from the fundamental understanding of a contract as expressed in the Upper Level Core Contract 208 7 Case Study I: The Business Contract Knowledge Management Project

Ontology. The Upper Level Core Contract Ontology shall have all the mandatory, recommended, and standard concepts for any legal business contract. Using that as a guide to interpret the contract, a user will be able to move towards the shared and template ontology subsequently.

Phase 2 is described with respect to a user starting from the Upper Level Core Contract ontology. The section is equally applicable to users starting from shared or template ontology, but they may have to work a little less to identify all the data and information.

Phase 2: Contract Instance Meta-data Extraction

Input: Contract Instance Document (paper or electronic), identified Specific Domain Level Contract Ontology from MTCO, USP2 Design Guidelines. Output: Identified Meta-data list/ Object Diagram. Process: This phase is the semantic concept view as described in the USP2 Design. Here we identify the main concepts of the particular contract. We refer to the Specific Domain Level Contract Ontology as the conceptual pattern identifying the generic concepts to be looked for. The objective of this phase is to search and retrieve the information in the given contract instance. Since the Specific Domain Level Contract Ontology itself has been designed following the USP2 Design, its sufficient, if the designer uses that itself as the semantic concept view pattern to analyze and extract information. But of course, the designer may make use of the detailed guidelines of the USP2 Design to identify the concepts, discover the relationships between them and so forth. However, for simplicity sake, we use the Specific Domain Level Contract Ontology as the conceptual pattern and proceed further. In this phase the designer needs to go through the contract and identify the following concepts as described in the steps below. All of them need not be found in all contract instances. But these are the recommended concepts to be included in a contract, to ensure it is legally valid and binding. Also all the concepts described below MAY NOT appear in the same order in a contract. The user is advised to go through the entire contract to identify the specified concepts. Step 1:

1 Go through the contract terms and identify who are the parties to the contract. (Concept identification step in the SCV) 2 Identify what roles they undertake to perform within the scope of the current contract being examined. (Semantic Relationships discovery, specially the actor- action, actor-object, concept-attribute type relationships). 3 Also extract the identification information given for each of the parties, like address, and certification number, etc.(Meta-data identification). 7.12 Deducing Contract Workflow Model: The Procedural Concept View 209

Tips: Usually, they are organizations or a person between whom the agreement is made is clearly stated and defined in the opening paragraphs it. It is a legal requirement that every contract MUST have clear identification of the ‘actors’ of the contract. The actors may have certain responsibilities to carry out in the context of the contract, ‘roles’. Say an organization may be buying goods from another, when it is generally termed as the ‘buyer’. The same organization may be selling to customers in another context, where it could be the ‘seller’. Thus, we have ‘actors’ playing a defined ‘role’ in a contract. Further descriptions and characteristics of an actor, or role can be seen in the conceptual model for the upper layer, and specific characteristics for a buy sell contract can be seen in the shared layer of Multi Tier Contract. Step 2: Identify the period or duration within which the said contract is valid. Tips: In some cases, only the contract valid from date or the date of signing may be explicit. In that case you will have to infer, the valid till date, by reading through the contract. If it is a framework contract, it may be specified that the period of contract is to be decided mutually. Step 3:

1 Identify the primary purpose for which the contract is being signed called the ‘object for consideration’ in legal terms. 2 Identify speciﬁc descriptions and/or speciﬁcations for the stated ‘consideration’.

Step 4: Identify the promises or guarantees made by each of the parties. Step 5: Identify the required performance which are expected to fulfil the promises. Step 6: Identify the rights and liabilities listed for each of the parties. Step 7: Identify the legal jurisdiction under which the contract is valid. Tips: In international commerce, it is important to state which law and/or jurisdiction the contract is valid. That would determine the court of law where all disputes would be tried and adjudicated. In e-contracts, further specific details regarding security, storage and other issues as discussed in the EC Directives’98 (EC Directives 1998 n.d.) would also need to be identified. Step 8: In case of e-contracts for e-commerce, identify technical specifications for messaging, and routing, etc. Tips: E-contract specifications as laid down by the EC Directives and other legal jurisdictions are being analyzed and carried out by various other research teams and organizations. For example, the Trading Partner Agreement of ebXML (OASIS 2002) deals exclusively with all technical parameters to be agreed for an electronic business. Detailed discussion of those parameters is not included within the current scope of this thesis. Step 9: Represent the entire identified objects and their data on an object UML diagram. Tips: This step is optional for those users not familiar with UML conceptual model- 210 7 Case Study I: The Business Contract Knowledge Management Project ing. It is sufficient to have identified the concepts and extracted the data in a simple list as well.

Phase 3: Obligation, prohibitions, rights, performance event identiﬁcation

Input: Basic Meta-data identified from contract instance in Phase 1 and 2. Output: List of obligations, their types and their actors/roles, the related performance required to fulfil the identified obligations. Similar lists for included rights, prohibitions may also be drawn up following the same strategy. Process: Step 1:

• Identify the main obligation(s) which each of the party promises to fulfil (from phase 2 we get basic idea) • Identify the required performance, which would fulfil the stated obligations. • See if any pre conditions, qualifying conditions or dependencies on the performance events are stated. Here, we may also use the temporal semantic relations (figure 6.9) as a basis. • See if any time-frame for performance execution is stated either explicitly or implicitly. • See if any place or location or point has been stated for the performance to occur.

Tips:: In case of commercial sale of goods, the seller promises to deliver the goods, then he is bound to the actual execution of performing all those actions, which would allow him to ‘deliver the goods’. That could even include the seller ordering his raw materials from his supplier. The seller may delegate the execution of the business events to other third parties unless otherwise stated in the contract. But in most cases, delegation of the performance does not imply delegation of the obligation. For example, say the seller hires transporters to deliver the goods to the buyer, and the transporters fail to deliver the goods, it would still be the seller’s responsibility to deliver, which would have failed. Generally, all performances are time bound. A seller, on receipt of a purchase order from the buyer, would necessarily have to deliver the ordered goods within a certain number of days or before a certain specific date. Such conditions are usually stated clearly on the contract. The time aspect is crucial in determining many of the distinction between a performance and a non-performance. Step 2: Identify the Unconditional Rights, like right to inspect, and right to cancel, etc. Identify the Remedial rights or Conditional Rights, like Right to Penalty, and Liability for risk transfer, etc. Tips: Guarantees, warranty periods, rights to inspect the goods are some examples of rights, which a buyer may enjoy under a typical commercial contract. Legal contracts should have explicit statements regarding the 7.12 Deducing Contract Workflow Model: The Procedural Concept View 211 process of dispute resolution and remedial actions for cases when one or both of the parties are dissatisfied with the performance execution. A breach of contract clause may be included to cover all possible scenarios, which constitute a non-performance or a contract violation. Step 3: Identify for each obligation, who is the owner and who is the ownee. Simi- larly also identify the rights owner and ownee as well as the prohibitions owner and ownee. Step 4: Identify for each obligation, the obligation type from the MTCO. Traverse the associations to get the related reciprocal, conditional, reconciliatory or secondary obligation. Step 5: • Look up the main performance events needed to fulfil each obligation, as identified in the previous phase, from the MTCO. • Look up the performance events that are prohibited under the list of prohibitions. • Look up the possible options for the identified rights. Step 6: Look up the non-performance events that are stated to cause unacceptable conditions or unfulfillment of obligations. Tips: Generally the violations of obligations are tied to the activation of related rights. Therefore an occurrence of non-performance would activate the associated right that in turn may activate reconciliatory obligations and so on. Thus this step is vital to identify and establish the inter-relationships between obligations, prohibitions and rights.

Phase 4: Obligation, Performance, and Non-Performance Inter-relationship Identiﬁcation:

Input: List of obligations, list of rights, List of prohibitions, list of related performance events and other identified inter-relationships identified in previous phases. Output: Time ordered list of obligations, the obligation states through which each individual obligation passes in response to the performance events. Process: Step 1: 1 The user has now to order the obligations. The ordering of the obligations is recommended on the nature of the obligation, that is the primary obligation should be the first to begin with, followed by the included secondary obligations, thereafter the reconciliatory obligations. Group the obligations by the obligation- ownee. 2 List all the rights of individual parties at the end. However they need not be ordered sequentially since some of their execution need not be compulsory or no time ordered choreography might be interpreted. 212 7 Case Study I: The Business Contract Knowledge Management Project

3 List any Prohibitions too, if stated.

Step 2: Separate the list of performance events ordered by the role player expected to perform the activity. Tips: Each list would ultimately lead to the business activity workﬂow as per the contract requirement for each of the organization involved. Step 3: Now order the activities sequentially in the order (with respect to time) they should be executed. Step 4: Note down any pre conditions or rules or policies, which need to be checked or enforced for any of the listed activities. Step 5: Identify the obligation states through which each identiﬁed obligation will pass through. Step 6: Identify which performance event is related to individual obligation state change for the listed obligations. Step 7:

• From step 1, the user should have separate list of obligations for each of the role players involved. • From step 3 and 4, the user will also have a separate list of performance events. • From step 5 and 6 the user now has a broken up detailed list of individual obligation states and their related performance events. Keep the same sequential time order the user is now required to merge the list of obligations with the detailed obligation state detail. • Thereafter, the user is to insert the time ordered performance events into the now merged list of obligations for the same role player. A similar process for the other role player will give the user another time ordered sequence of obligations and performance events. • Now the user is to place both the ﬂowchart like time ordered contract obligations and performance event lists for both role players side by side. The user should be able to see the points of interaction between the two lists. The user has to simply link the points of interaction. Any pre conditions or policies are to be superimposed to get the binding conditions.

Tips: They are usually the obligation state changing performance events initiated by the beneficiary of the activating obligation. For example, for obligation to deliver state change from ‘triggered’ to ‘fulfilled’ for a seller is initiated by the performance event of acceptance of delivery by the buyer. Also, pre-conditions like delivery acceptance notification must be done within 7 days of delivery should be written on the inter-connecting link. 7.12 Deducing Contract Workflow Model: The Procedural Concept View 213

Phase 5: Optional mapping to existing Business Process Workﬂows

Input: Deduced list of performance events and activities from the contract from phase 3, business process workflow model of the organization to which the contract is to be mapped. This phase is an optional phase to be carried out in tandem with the phase 4 described above. The existing business process flow will provide precise identified business activities to be included in lieu of the performance events list. User may step over this optional phase directly to phase 6 if no such input business process flow is available. Output: Merged and mapped business process event list, with identified points of tracking obligations. Process: Step 1:If a business process workflow or ontology describing the regular internal business workflow is available, then the user may now try to map the inferred list of performance events to the list of activities in the business workflow. Similar terms may indicate the same event. Step 2: The internal business workflow model would enable the user to break up some of the more abstract or major performance events, like ‘packaging’ in to more practical sub processes and events like ‘get material’, ‘get dimensions’, ‘pack goods’, and ‘mark the goods’ etc. The identified common events between the obligation state changes related performance events list and the business process events, like for example, ‘acknowledge receipt of order’ are the common points of integration between the contractual workflow and the workflow of the business organization. On the other hand a similar, ‘send order’ from the buyer’s list would be the counterpart of this mapping of business and contract workflow integration. Since the identified points of integration in effect change the state of the obligation, they are useful in monitoring and tracking the commitment fulfilment process.

Phase 6: Contract Workﬂow Sequencing

Input: Time Ordered list of obligation, obligation states, and the related performance events (or business events in business process workflows) from phase 4 (or from phase 5 if mapping has been done). Output: CWM using chosen representation language be it Event-Driven Process Chain notations or BPMN or Petrinets, for the flow of contractual obligation fulfilment. Process: Step1:The user first represents the list of time ordered obligation states and their performance events from Phase 4 (or phase 5) in a graphical form using the event- driven process chain notations as discussed earlier (chapter 4.1). Obligations are mapped to functions and performance events to events. 214 7 Case Study I: The Business Contract Knowledge Management Project

Step 2: The user connects the events and functions with arcs and logical connectors. The logical connector to be used OR, XOR or AND is to be decided by the user following the agreed statement in the contract. A choice of OR is usually the case when the obligation owner is given an option of choosing one or more than one alternatives for obligation fulﬁlment. Example, when the buyer may choose to have his remedy for unsatisfactory delivery as a ‘penalty payment’ and ‘a redelivery of goods’. A XOR connector is used whenever the obligation state transformation can occur by the function of any of several alternative performances. A sample contract example using the EPC notations can be seen in our appendix A.3, ﬁgure A.6. Tips: Remember, in the event-driven process chain notation, the functions represent obligation states, the events the performance event required to change the state of the obligation.

We have also used BPMN to model the contract workflow model, as we shall discuss shortly.The BPMN is an expressive, graphical process modeling notation, easy understandable by process modelers. In (Kabilan 2005), we have defined the core mapping patterns between the concepts of the CWM and the BPMN: - The performance event to the BPMN sub-process. The obligation states to the BPMN events. -- The choreography of performance events to the BPMN sequence flow. - The simultaneous processing of two or more performance events to the BPMN AND gateway. - The exclusive processing of performance events to the BPMN XOR gateway.

7.12.4 Using BPMN to model CWMs

In this section, we now motivate our choice of BPMN as the formal representation language for CWM. We use CWM-BPMN to further map to internal business process models,as discussed in section 7.13.1. The choice of BPMN as the formalization language was based on the several features of BPMN. We discuss the advantages and disadvantages of BPMN below:

• BPMN is more expressive than other similar languages like UML activity diagrams, UML Sequence Diagrams, formal colored Petri nets. It is especially suitable for the contract -business process domain, as it gives us the flexibility to capture the domain specific semantics involved. BPMN uses two levels of information representation. On the first level, the graphical notations are simple to understand. On the second level, each BPMN construct defines a set of attributes that can be used to convey a richer specification. In case of CWM, we have used user-defined attributes to model the specific characteristics like individual ObligationState of 7.12 Deducing Contract Workflow Model: The Procedural Concept View 215

each Obligation. In this regard, we found the expressive capacity of BPMN to be advantageous over others like UML activity diagrams. • BPMN is graphical in nature. Thus affords easy understandability to both business process modelers, as well as domain experts including lawyers, information system experts and business management and decision makers. At the same time, the set of non-graphical attributes render BPMN as a powerful notation to map to Business Process execution languages. • BPMN is appropriate to model abstract high-level ‘black box’ processes, collaboration patterns and sequence diagrams, all in one single Business Process Diagram (BPD). • BPMN allows the different parties to have different perspectives of the entire BPMN diagram. The CWM expressed as a high-level abstraction gives all parties involved an idea of how each role player would act and their overview of the process execution. At the same time, low-level business process details may be encapsulated within the same abstract high level CWM. Each role may have a different view of the entire CWM. For example, the buyer needs to know that his counterpart, the seller would ‘make goods’ in response to his ‘send PO’ task. But the buyer does not see exactly how the seller ‘makes his goods’. Whereas, the seller should be able to drill down to see his internal business activities which may include, ‘get supplies from the supplier’, ‘order extra workers to assemble the goods’ and ‘pay for supplies’. • BPMN can be mapped to a number of low-level specification languages (machine executable) like BPEL4WS, RosettaNet, ebXML and BPSS. Thus, the graphical CWM can be made operational. • The graphical elements of BPMN can be extended to adapt for domain specific purposes. Though BPMN restricts addition of new core elements, it allows the modeler to add user-defined attributes, change format and layout specification (except a few reserved ‘keywords’ like layout specifications). For example: the three types of events, start, intermediate and end event defined can be defined to have different internal markers to specify additional information. Some basic types like Message, Rule, Link, Compensation, Error and Timer have already been pre-defined. Additional markers may be specified for each Obligation State. In this current document, we have used the existing markers of timer and message to denote the different obligation states.

7.12.5 CWM-BPMN Transformation Patterns

The CWM patterns are based on the application of the Workflow Patterns as proposed in (van der Aalst, ter Hofstede, Kiepuszewski & Barros 2000b, van der Aalst, ter Hofstede, Kiepuszewski & Barros 2000a). The other theoretical background is 216 7 Case Study I: The Business Contract Knowledge Management Project the BPMN specification. The basic patterns as suggested by Van der Aalst et al. have been restricted or specialized for the contract and business process domain and proposed as the contract workflow CWM-BPMN patterns. The workflow patterns are useful for the business process modeler to analyze and interpret which case scenario fits the contract instance best. The main inputs to the business process modeler (also an IS designer) are the contract knowledge base, MTCO, the actual contract instance, the set of CWM-BPMN transformation patterns and optionally the existing internal business process model. It need not be a machine-executable business process model, but simply a source of information regarding the usual manner in which similar business activities are executed by the concerned business enterprise. The objective is to use business process or activity terminology so as to identify the performance events in the CWM as close as possible to the ones currently in practice within the enterprise. We use the same typical business contract scenario discussed in the previous sections to illustrate our CWM-BPMN patterns. When no previous process models exist then the CWM itself is the high level business process model. The CWM deduced from the contract instance and the MTCO may use concepts or terms from related ontologies like the enterprise ontology, business process management ontology. In which case, the natural language interpretation of the performance events is replaced by precise business activities or process names. In case there is a pre- existing internal business process model then the task of the process modeler is to compare the deduced CWM and the pre-existing business process models to check for contract compliance. The CWM provides the boundary conditions within which the existing business process model can be allowed to vary and yet be compliant to the contract. In case the existing process model violates the CWM then the business enterprise runs the risk of contract violation. When no business process models exist then the process modeler needs to formalize the high level CWM in to an executable business process model. The CWM-BPMN patterns provided below are an aid in this direction.

Pattern 1: Contract -Business Process

Description: The activities of each partner are modeled as a sequence of processes or a workflow within one swim lane each in a single pool. In case, a detailed level of modeling showing all sub processes is required, then multiple swim lanes for each partner /actor/role may be used. Care has then to be taken while modeling the inter enterprise communication through the use of messages. It is thus recommended that two different levels of abstraction are maintained for clarity and easy understanding. Examples: The performance activities as identified to the seller are modeled as a sequence of business processes in a single swim lane, whose name is represented as 7.12 Deducing Contract Workflow Model: The Procedural Concept View 217 the role or actor from the contract. Similarly another Lane is attributed to the buyer, one to the carrier and so on. The entire CWM consists of this set of inter related swim lanes and is equivalent to a pool in a Business Process Diagram (BPD). In the sample CWM given in figure 7.18, we see that the interaction between the Buyer and the Seller are represented as separate swim lanes. BPMN mapping: Swim lane, Pool Fig. 7.18. A Sample Contract Workflow Model using BPMN 7.12 Deducing Contract Workflow Model: The Procedural Concept View 219

Pattern 2: Performance Events

Description: The performance events and non-performance events from the MTCO are mapped to Activity, Process or Sub-Process in BPMN. The choice of activity, process or sub process depends upon the level of abstraction used. Usually at the CWM, only partial information may be available, so a modeler can infer only processes or sub processes. Activity may be identified at the time of detailed low- level internal business process model description or when mapping to pre-existing process models. Examples: In the case scenario illustrated in figure 7.18, examples of Performance Events associated with the buyer are Send PO, Inspect Goods, and Send Cancelation. Similarly those of the seller are VerifyOrder, Make Goods, and Package goods. In this example, we see that send PO is an identified task, hence modeled as a BPMN Ac- tivity, whereas, Verify Order involves internal order verification process and thus modeled as a BPMN collapsed Process. It has been used as a black box to hold the internal workings of the seller. BPMN Mapping: Activity, Process, and Sub Process.

Pattern 3: Obligation State Changes

Description: The contract- business processes between the two parties have certain obligations that are required to be fulfilled by the execution of related activities. The activities themselves are represented using activity or process or sub process. The obligations are modeled as events in BPMN. The initiation or triggering of these sequences of activities is represented by a start event. The start of a cycle of contract execution may be triggered by some external activity like the other party sending a purchase order. This dependence on other external factors for the start (triggering) of the contract obligation fulfillment is represented by message start event. The same performer may trigger sub processes within the CWM only on completion of other processes/activities. But it may also be that the counter party expects certain response or activity. Thus, this dependence of external factors should be modeled as intermediate message event. In case there is a certain predetermined time out period, then we should model the condition as a timer. In case, when some internal business policy or rule triggers a process, use rule start/intermediate event. The process modeler may make use of the other attributes of the event types to capture specific aspects of the obligations (from the MTCO) like the obligation state name, obligation type, the obligation owner, obligation ownee (the performer,or the role for the swim lane would be the obligation ownee). Examples: The arrival of a purchase order from a Buyer initiates the primary obligation of the seller to deliver goods. Since the entire process is triggered by 220 7 Case Study I: The Business Contract Knowledge Management Project buyer’s activity, we model the input as a Message Start. Alternatively, the business process modeler may choose to connect the Message Flow directly to the responding business process or activity on the seller’s workflow, in which case he MUST note the obligation state changes on the message expression attribute. Figure 7.19 takes a closer look at the above-mentioned scenario. BPMN Mapping: Start event, intermediate event, and end event.

Fig. 7.19. Pattern 3: Contract Obligation State Changes

Pattern 4: Performance Events Sequences

Description: Choreography of activities/ processes is represented as a sequence. The time line in which they need to be executed orders the performance events identified for each partner. The general flow of events is depicted by BPMN sequence flows. The type of sequence flow used depends on the nature of decision to be made (gateways) and controlling conditions to be expressed. Examples: The seller on receipt of an order is obliged to send an acceptance or acknowledgement to the buyer. Inactivity implies acceptance. But to do so, he MUST verify the order, maybe check the status of the buyer (buyer’s credit history), and maybe be the seller needs to check his production schedule to see if he can meet the deadlines, or maybe he has to check with his supplier for availability of supplies. BPMN Mapping: Sequence flow.

Pattern 5: Simultaneous Processing

Description: An AND gateway is used to describe simultaneous processing of several sub tasks or processes in parallel. An AND gateway is also used to synchro- nize other activities. 7.12 Deducing Contract Workﬂow Model: The Procedural Concept View 221

Fig. 7.20. Pattern 4 and Pattern 5: Contract Performance Event Sequences and Simultaneous Processing

Examples: The seller makes goods at the same time he also arranges for carrier, and procures packaging material. The seller would wait for all the three parallel processes to be finished before he notifies buyer that the goods are ready. (See figure 7.20, this is an expanded version of the Verify Order sub process shown in figure 7.19). BPMN Mapping: AND Gateway.

Pattern 6:Communication between the Parties (Performers)

Description: The time ordered sequence of the activities or performance events is segregated in to performer-wise groups. The communication between the two groups (swim lanes or pools) is represented using Message Flow connectors. Mes- sage flow may also be used to represent the performer and the performance owner (for whom a task is being carried out). Examples: The buyer sends an order to his seller. In the swim lane for the buyer, this is represented as ‘send order’ process. From the MTCO, we can deduce that the beneficiary of this performance event if the seller. Thus the communication between the two is modeled using a message flow. (Source is the send Order process in the buyer’s process diagram the target is the seller’s process.) If the corresponding event or obligation is not identified then the message flow shall connect to the seller’s swim lane boundary else to the appropriate message or obligation state event type. In the above case, the receipt of the order changes the ObligationtoDeliver state from Inactive to Active for the seller. Thus the target of the message flow is an obligation state (message type) start event. BPMN Mapping: Message flow. 222 7 Case Study I: The Business Contract Knowledge Management Project

Pattern 7: Exclusive Processing

Description: An XOR gateway is used to describe situations when the actor has to choose ONE from a set of available options. A default gateway option may be indicated. A conditional outﬂow may also be modeled using the conditionExpression attribute of the out going sequence ﬂow. The choice may be made based in data available in the Business process diagram, and then the XOR gateway may be of type Data-based Gateway. If the choice is made on the occurrence of certain event or trigger from the other party (intermediate event in the current business process) then an event-based XOR maybe used. Examples: The buyer is entitled to cancel his order within 7 days from the date on which the seller receives his order. So in case, he sends his cancelation,then the seller is faced with a decision to make:

• If the cancelation came within 7 days from the order date, then the seller has to accept the cancelation unconditionally. This is the default outgoing sequence ﬂow condition Expression is set to a string expression of ’cancel-date<= (order− date + 7). • If the cancelation is received after 7 days; the seller may reject the cancelation. That is the buyer owes the seller entire payment for the ordered goods irrespective of whether the buyer takes the delivery or not. • The cancelation is received after 7 days and the seller has started to make goods. But the seller may choose to accept the cancelation with a penalty fee applied. • If the cancelation came after 7 days, but the seller has not yet begun production or for some internal reasons has not acted on the order, then he may choose to accept the cancelation, though he was entitled to reject the cancelation

As seen above, this scenario may be modeled as an event-based gateway with conditional expressions associated with the sequence flows. Alternatively, the situation may be broken down in to a series of gateways to handle all the aspects defined above. The final choice rests with the business process modeler. BPMN Mapping: Event based Gateway

Pattern 8: Remedial Options Choice

Description: In case of deviations, one of the business partners usually has a number of remedial options (rights, permissions) available to him. It may be possible that one or more of the available options may be chosen. The choice is quiet complex and is dependent not only on the data within the CWM but also is inﬂuenced by management policy, and legal jurisdiction etc. The scenarios should be modeled as a complex decision, signifying human intervention. 7.12 Deducing Contract Workﬂow Model: The Procedural Concept View 223

Fig. 7.21. Pattern 7: Exclusive Processing

Examples: The goods delivered to the Buyer are not of acceptable quality or according to the speciﬁcation agreed upon in the contract. The Buyer may have the option to:

• Reject the entire delivery. • Reject the defected goods only and accept the rest. • Seek replacement for the rejected goods. • Seek compensation due to inconvenience cased by this non conformance be obliged to deliver the ordered goods to someone else, so this deviation from the seller makes the buyer default on his other obligations. • Based on previous history with the seller, the buyer may choose to do not to anything but send a warning. In this scenario, the buyer may choose one or more of the above options. His choice would be a complex decision. (See ﬁgure 7.22)

BPMN Mapping: COMPLEX Decision Gateway. In the next section, we shall see how such contract workﬂows can be used for facilitating interoperability between enterprise systems. The work on the alignment of contract to business processes and exception handling process patterns is the result of a collaborated research between the author and Jelena Zdravkovic. 224 7 Case Study I: The Business Contract Knowledge Management Project

Fig. 7.22. Pattern 8: Remedial Options

7.13 Uses of MTCO and CWM

Now we shall look at some illustrative uses of our proposed MTCO and the CWM in the following sections. As said earlier, we shall restrict ourselves to the overview of these applications in this thesis. The proposed uses for decision support, interoperability of enterprise systems and management of contract knowledge are some examples of how an ontology for Information Systems may be used. Thus, our second goal of exemplifying how ontologies may be used in Information Systems is fulﬁlled.

7.13.1 Alignment of Contract to Business Process Models

The deduced Contract Workflow Models should be aligned to the actual business process models. There may be a business process that the enterprise may be following, or there may be none. In the later case, the deduced CWM becomes the internal business process model that the enterprise should adopt. In the first case, there is a need for aligning the existing business process models with the contract compliant model. Also, in reality a given enterprise has business relationships with more than one other business entities, therefore, there would be more than one contract that is valid. It is impractical that an enterprise will modify its existing business process to each of the new contracts agreed to. More realistically, the enterprises will enter in to contractual agreements that are closest to their internal business processes, to begin with. Otherwise, they will map their existing internal processes, in such a way that the contractual agreement is not violated. Therefore, the need for alignment of the deduced CWM to Business Process Models, is established. Zdravkovic & Kabilan (2005a) have proposed a conceptual framework for business process models using BPMN as a representation language. We define a set of 7.13 Uses of MTCO and CWM 225 rules for compliance between CWM and business processes for each of the above mentioned aspects. We do not go into details of those rules here in this thesis but refer the interested reader to our publication. Zdravkovic also puts forward a mechanism for assessment of business processes to assess if they are complaint to the contract or not.

7.13.2 Contract Execution Monitoring

The proposed MTCO and the Contract Workflow Model has been assessed in another research work by Chen (2006). Chen has analyzed a typical contractual agreement for transportation services between carrier and shipper using the prescribed MTCO as a base. Chen follows the guidelines discussed in previous sections and puts forward a conceptual model for a transportation service agreement. He further follows the CWM methodology to analyze the agreement compliant process model. Chen, thereafter, extends his analysis for several business case scenarios, and uses process mining framework and tool PRoM, proposed by Van der Aalst to simulate the possible execution scenarios. Chen’s work lays the foundations for a conformance checking of intended and actual contract execution. The interested reader is referred to Chen’s work for further reading and explanations. For the current thesis, the above mentioned research is valuable in the following contexts: • The utility of MTCO as a contract knowledge base is ascertained. • The design guidelines for deducing the contract compliant workflow model is also validated. • We note that our proposed CWM methodology is representation language independent, since we ourselves have only exemplified using EPC diagrams and BPMN, Chen has used Petri nets to model his contract compliant workflow models.

7.13.3 Exception handling of Process Patterns: Analyzing Prescriptive Behavior

Once signed, a contract is to be realized by an executable business process model. As we explained in the previous section, a contract specifies possible obligation violations and how they are to be resolved. A business process must have capability to realize contractual violations by realizing chosen remedial procedures. A problem is that business process models typically specify only the ‘successful’ flow of events. Protocols for exceptional flows are usually not designed, due to two main problems: (i) Exception flows cannot be anticipated, (ii) Specification of too many exceptional flows greatly increase complexity of a process and decrease its readability and maintainability. 226 7 Case Study I: The Business Contract Knowledge Management Project

However, one of the main considerations in design of effective processes is supporting broad exceptions originating from contractual violations. In order to enable handling of undesired contract occurrences by business processes, to solve the first outlined problem, it is necessary to systematically anticipate possible exceptions, and to select appropriate exception handling procedures. For solving the second problem, we propose defining every exception procedure (i.e. exception handler according to the MIT Process Handbook) in the form of a process pattern. Every pattern defines a self-standing process template intended to be executed when a particular exception occur. In a typical business trade contract, a seller agrees to ‘sell’ something of value or interest to the ‘Buyer’ who in turn agrees to ‘pay’. They agree on what the acceptable conditions for satisfaction are, as also some contingency plans and options on how they will resolve their differences, in case the transaction does not go according to agreement. There are explicit statements as well as implicit understandings and best practices embedded in a physical contract. There are obviously elements of procedural aspects. The expected Performance Event for fulfilling the obligation to deliver is that of ‘Delivery of Goods’. This performance is deemed to be violated that is UnfullfilledBy an occurrence of a Non-Performance Event under a set of circumstances like (a) the delivery is late (Late Delivery) (b) the delivery is on time but the goods are not as per the specification (Goods Unsatisfactory) (c) the seller does not deliver any goods at all (Failure To Deliver). Each of these contract violations may be resolved via a number of options as identified by the Conditional Rights, like for example:

• Right To Seek Re-Delivery: the Buyer may choose to seek replacement of the faulty goods, in the case of ‘Goods Unsatisfactory’. • Right To Penalty: Buyer may impose a monetary ﬁne for late delivery or unsatisfactory delivery. • Right To Cancel: The Buyer may cancel the speciﬁc order instance. • Right to Terminate: In extreme cases, the Buyer may opt to terminate all trading relationships that is cancel the contract in itself.

A combination of these rights is also possible, like the Buyer may choose to opt for re-delivery AND a penalty. We model ‘constraint’ like conditions that are described in the contract, using Object Constraint Language in the conceptual models. Syntactically these may be represented using Common Language (as recommended by the ODM) or even Semantic Web Rule Language. An example of such a constraint may be given as follows:

If a delivery made by the Seller is late or not can be determined by examining the DeliveryTerms to see the agreed DeliveryTerms.Period (say 7 days for example) Then, assuming that every single contract execution, will 7.13 Uses of MTCO and CWM 227

have an order date and /or an expected delivery date(Order.OrderDate). It is implicit that the actual delivery date for that particular order should be within the agreed upon delivery period. So, if the actual delivery date (DeliveryofGoods.DateAndTimeOfDelivery) is more than agreed upon delivery date then it is a case of Late Delivery, which activates the conditional rights of the Buyer as described earlier (each conditional right has a set of states just like the obligation states of inactive, active, triggered, fulﬁlled)

This enabling condition(s) can be represented in OCL(s) as: Example 1: IF DeliveryofGoods.DateAndTimeOfDelivery > Order.OrderDate + DeliveryTerms.Period THEN LateDelivery = True Example 2: IF Late Delivery= TRUE THEN ConditionalRight = TRUE In our ongoing work in this context, Zdravkovic and Kabilan are focusing on the modeling of exception handling patterns for resolving aforementioned contractual violation related exceptions. Each pattern addresses a speciﬁc violation and proposes a solution on how that exception is to be resolved and by whom. These patterns themselves are expressed as ontological conceptual models named Exception Handling Process Pattern (EHPP) Ontology. Next, we shall see yet another application of the MTCO with pragmatic aspects associated with it. For example, the risks associated with a contract and its execution. Some typical risk related questions maybe: who bears the risk, in the situation of unforeseen event or accident taking place? How is the risk to be controlled? How can the damage be limited? How can such contractual risks be averted? We discuss these issues in our next section on risk assessment of business contracts. The work on business contract risk assessment is a part of a collaborated joint research between this author and Hans Weigand of Tilburg University.

7.13.4 Business Contract Risk Assessment

Business organizations conducted business transactions for centuries. With the electronic revolution the mechanism for establishing these business and trade relationships have changed drastically. Interoperable systems have become indispensable for supporting transaction execution. In the near future, they are expected to play in- creasingly a supporting role in the establishment of the relationship as well. One of the supporting roles could be the establishment of trust. There are many factors that govern the formation of business relationships - like business compatibility, value or service profitability, and business policies, and amongst these also trust. The question of trust arises when a business enterprise decides to enter in a trading relationship with other business enterprises, especially in cases when the proposed partner is as 228 7 Case Study I: The Business Contract Knowledge Management Project yet an unknown candidate. The purpose of establishing legal contracts is manifold: to comply to the governing judiciary and regulatory frameworks, to make explicit all obligations and expected fulfilling activities, to formulate mechanisms for dispute resolution and remedial options in case of non fulfilment of promised activities and to divide the costs, liabilities for damages and risks involved in a pro-active manner. E-contracting facilitates business entities to offer and negotiate these business contracts electronically without even having physically seen each other. Hence, the need for assessing and evaluating the pros and cons of a contract offer from different perspectives is paramount. In the (Kabilan & Weigand 2006) we propose a method to systematically analyze and make explicit the risks associated with a business contract. We present an overview in this section. There are numerous risk assessment methods and models available in the areas of auditing, investment analysis, and critical mission design, among others. The methodology that we propose here is a combination of existing methods tuned to the contract drafting and contract assessment. Like the CORAS 4 project, our approach is model-based, but we focus on e-commerce transactions and contracts rather than IT-critical systems. The proposed business contract risk assessment method contains the following main steps as discussed by us in (Kabilan & Weigand 2006): Assumed Inputs: The contract draft proposed, business model or value model for the enterprise carrying out the contract assessment, reference contract, business and risk ontology wherever available and risk mitigation and control patterns like that proposed by Karteseva, Tan & Gordijn (2004).

1 Identiﬁcation of primary obligations. The underlying assumption for starting here is that we regard non-fulﬁlment of obligations (by either party) to be the main risk in interoperable systems. 2 Scenario modeling. From the primary obligations, the risk events can be derived as being the non-performance of an obligation. The risk events usually do have a temporal sequence. With scenario modeling, these partial orderings are presented. 3 Global risk assessment. Using the Event Tree method, identify the risks for each possible scenario (combination of risk events). The risk is expressed in the form of a probability estimate and a utility loss estimate. An aggregate risk can be computed over all the possible scenarios.

4 The EU-funded CORAS project (IST-2000-25031) developed a tool-supported methodology for model-based risk analysis of security-critical systems. The project was initiated in January 2001 and successfully completed in September 2003. For more details refer http://coras.sourceforge.net/ 7.14 Case Study I: Discussion of Results 229

4 Detailed risk analysis. The risk of a scenario may be broken down using a Fault Tree Analysis that analyzes the causes of non-fulﬁlment. These will be different for different situations, but some general analysis format can be used as a heuristic. In addition to this backward looking analysis method, a forward- looking Event Tree method can be applied. 5 Risk mitigation. The risk assessment is typically followed by risk mitigation. In this phase, preventive and compensating risk measures are considered. The effects of these measures should be assessed again by extending the Event Tree and then repeating step 3-5. Examples of risk measures are down payments, a letter of credit procedure, trust dependencies and sanctions. In a rational decision process, multiple alternatives are generated and compared before the best one is chosen.

Based on the above methodology, we propose a set of business contract risk mitigation patterns that are themselves conceptual modeling patterns like the DAM and ECA rule ontology. We also proposed a Business Contract Risk Ontology to be used as an input for the business contract risk assessment methodology and the selection of the appropriate business contract risk mitigation pattern. Details of the business contract risk ontology may be seen in (Kabilan, Johannesson, Ruohomaa, Moen, Herrmann, Ahlfeldt & Weigand 2007). Work on the risk mitigation patterns is still ongoing and we shall publish the results later.

7.14 Case Study I: Discussion of Results

We do not delve deeply in to this area, as the purpose of this thesis is on the conceptual modeling of domain knowledge, which we have been doing by illustrating how we apply our proposed O4IS in the business contract area to extract different aspects of the domain. In addition to the semantics of the business contract, we have seen the procedural concept view modeled as the contract workflow model. We have seen the utility of making such aspects explicit in different situations, namely: (a) For supporting inter-enterprise co-operation and interoperability; (b) For ensuring contract compliance, and (c) For exception handling of business processes. In this case study, we have analyzed and discussed some of the salient features and problems faced in the integration of contract management with business process management. We have analyzed the contractual domain in depth and proposed a framework for integrating all the three visualized perspectives of a contract through the use of MTCO. Starting from a contract instance the case study has proposed a methodology for arriving at the CWM. The proposed MTCO and the CWM methodology build on several theories (section 7.5, including the proposed Ontology for Information Systems Design Methodology. We have also seen the multifold use of 230 7 Case Study I: The Business Contract Knowledge Management Project the USP2 design for analyzing the different perspectives of the domain. Given that the primary objective for this case study was making implicit contract semantics explicit for the purpose of managing a contract compliant business process, we have not fully utilized the pragmatic concept view of the USP2 Design. The Procedural Concept View, presented in this case study is deduced via the contract workflow methodology, which in turn is based on the USP2 Design. The CWM methodology is, thus, a domain specific methodology for analyzing and bringing forth the Procedural Concept View. We conclude that a shared understanding is the key to solve the existing problems in the field of contract management. As proposed, ontology is useful as an interpreter or translator between the legal language, business language and the In- formation Systems language. Based on a common knowledge base, almost all phases of contract life cycle may be modeled and managed. However, this research has focused only on the contract execution phase. The approach methodology is to be extended to cover other phases of contracting from drafting to signing. This research has tried to reuse and integrate several related research methodologies and approaches. Proof-of-Concept implementations have demonstrated the practicality and usability of the proposed MTCO conceptual models in the practical Information Systems domain.

7.14.1 Summary of Case Study Contributions

Given below is a brief summary of the original contributions of this research that aim to achieve the main research goals and objectives of this thesis as stated earlier in the beginning of this chapter.

• To fulfil the objective of fostering shared, re usable understanding of legal business contracts: this case study research has proposed a framework for capturing and modeling the relevant contractual knowledge and information in a Multi-Tier Contract Ontology (MTCO). The framework has been further been populated with conceptual models for the generic business contract (Upper Level Core Contract Ontology), a typical sale of goods contract and other related terms (Specific Domain Level Contract Ontology) and models for Template Level Ontol- ogy. Emphasis has been laid on the analysis of obligations, their types, nature and relationship to expected performance. This is a significant aspect of this research, which makes monitoring of contract fulfilment feasible. • In the goal of bridging the gap between business process management and contract management: This research has proposed the use of MTCO as an interpreter for translation between the legal, business and information system domain languages. Thus the common shared, knowledge base, MTCO is the bridge based on which the gap between business process management and contract manage- 7.14 Case Study I: Discussion of Results 231

ment is visualized. To achieve this, this research has proposed a methodology, CWM, which aids in not only monitoring the contract execution but also helps in designing contract compliant business workﬂows. Continuing work in this regard is aimed to further narrow down the existing gap.

Some of the key artifacts that are novel contributions from this case study include:

• MTCO: The Multi- Tier Contract ontology along with all its analyzed models for the sale of goods, and Incoterms is a major contribution. • Obligation State Analysis: The analysis and classiﬁcation of contract obligation types and the pragmatic states that each obligation passes through is unique contribution. The utility of the obligation state analysis in performance monitoring, business contract risk assessment has been put forward. • CWM: The contract workﬂow model as a Procedural Concept View and the methodology to deduce it is useful in a number of situations. Firstly to make the implicit domain knowledge explicit. Secondly to offer a clear picture to human interpreters who are not familiar with legal terminologies. Thirdly, to align, plan and integrate the contract compliant process model into the internal business process model. Fourthly, to match and assess how far the actual execution of the contract followed the agreed plan. As we shall see later in the other case study, the CWM methodology can be generalized and applied in other domains as well. We apply the same philosophy and deduce the Procedural Concept View for the military operations doamin. • Business Contract Risk Assessment Method and Business Contract Risk On- tology: A methodology based on our MTCO and obligation state analysis for business contract risk assessment has been proposed. Business contract risk ontology for the same has also been proposed though not included in this thesis. Details may be referred to in (Kabilan et al. 2007). • Exception Handling Process Patterns: This research is still ongoing and the purpose is to put forward a series of patterns for exception handling situations based on the agreed upon contractual terms.

O 8

Case Study II: The Defence Conceptual Modeling Framework Project

In this chapter we present the second of the two case studies where the theories discussed earlier have been put to use. The experiences have been the feedback necessary to evaluate and reﬁne our proposed methodologies. Given the scope and depth of the case study to be discussed in this chapter, we begin by presenting an overview of the contents and structure of this chapter, as illustrated in ﬁgure 8.1.

Fig. 8.1. Case Study II- Chapter Disposition

We shall begin by a description for the case study, thereafter a short background for the military modeling and simulations domain, focusing on military operations(section 8.1). We discuss the role that ontologies have to play in the context of this case study (section 8.4). We present the overview of the proposed ontology (section 8.6). We do not go deep into the ontology and its descriptions. We restrict our discussion to the method applied, namely the O4IS design methodology and the USP2 Design in this particular case study(section 8.5). In this case study we give illustrative examples of how we have used the Semantic Analysis Relationships as patterns for analysis in section 8.7. We conclude by an overview of some of the targeted application in which the proposed ontologies are intended to be used (section 8.8). Given the scope and limitations of this thesis, we do not describe in detail the ontologies, their applications. Interested readers may read more about them in other publications like (Mojtahed, Garcia, Kabilan, Andersson & Svan 2005) and (Kabilan & Mojtahed 2006b). 234 8 Case Study II: The Defence Conceptual Modeling Framework Project

8.1 Case Study II Background

One of the main objectives for military modeling and simulation has been to support effective training programs through virtual simulations of military operations. One of the many components needed to realize are re-usable Mission Space Models (MSMs). MSMs are conceptual models describing the real world abstractions capturing not only the static semantics but also the dynamics, behavioral patterns and the pragmatics of each military action involved. The Swedish Defense Research Agency (FOI, www.foi.se), which goes under the Ministry of Defense, conducts research in the ﬁeld of methods and technologies for Modeling and Simulation, as well as par- ticipating in activities concerning development of compound and complex computer models. DCMF has its origin in an American concept called Conceptual Models of the Mission Space (CMMS), which was introduced by US DoD in their Modeling and Simulation Master Plan 1 in 1995 to address the same problem. The CMMS concept, which was presented as an important component in this vision, was according to DMSO an essential requirement for interoperability and reusability of knowledge in the military domain. For unknown reasons the CMMS concept was never completed and the activities in it seemed to end around 2001. However, FOI found the concept interesting and has, since 2002, conducted research on the concept to explore its potential. FOI has been involved in the knowledge extraction, representation and modeling design, development of knowledge components including a reusable ontology called the Defence Conceptual Modeling Framework-Ontology (DCMF-O). DCMF is a framework for making conceptual descriptions and models of military operations. It consists of tools for their development and reusability, as well as standards for acquisition, representation, modeling, integration, management and preservation of knowledge. The Mission Space Models (MSMs) which are kernel to both the original CMMS and the current DCMF are simulation and implementation- independent functional descriptions. These functional descriptions are related to real world processes, entities, environmental factors, and associated relationships and interactions constituting a particular set of missions, operations or tasks. DCMF is also a framework for the development of models and it captures the characteristics of objects in a domain given by a scenario, such as their features, interactions and behavior. The models, or rather Mission Space Models (MSM’s) strive to be generic and applicable to as many scenarios as possible without any loss of critical knowledge. The DCMF Framework consists of:

1 DMSO. DMSO 1995 Master Plan. 1995. http://www.dmso.mil/briefs/msdocs/policy/ msmp.pdf. Last accessed 2001-10-05 8.2 Functional Requirements of the DCMF Project 235

• The DCMF Process: The overall process to be followed for the capture, analysis, modeling and use of military knowledge to formulate the MSMs. • The DCMF Ontology Suite: The knowledge base to be used as a look up dictionary, as a source of information, as analysis patterns as well as to facilitate semantic interoperability between other command and control military Informa- tion Systems. • The Knowledge Meta Meta Model as a pattern for speciﬁc military operative knowledge representation. • Applications and Tools for applying the DCMF process. Since military missions are based on activities, the conceptual models must be action centric and not object centric like most other domain ontologies. The conceptual models must not only show the structure and order of the military actions but also their cause, conditions and effects, in short, the pragmatics of the actions are to be captured along with their semantics and context.

8.1.1 DCMF Project Goals

The DCMF project was launched in 2003 with the following goals: • To produce a disciplined procedure by which the simulation developer is systematically informed about the real world problem to be synthesized. • To deploy a set of information standards the simulation subject matter expert (SME) employs to communicate with the Military Operations SME. • To provide a real world military operations basis for simulation speciﬁc analysis, design, and implementation.

8.1.2 DCMF Project Objectives

Thus the overall objectives for the DCMF project is to capture authorized knowledge of military operations; manage, model and structure the obtained knowledge in an unambiguous way; preserve and maintain the structured knowledge for future use and reuse. And the premier aim of doing so is enabling semantic and substantive interoperability of the future simulation models built on these descriptions. The DCMF project consists of several components ranging over architectural, knowledge components, analytical tools, compositional and retrieval mechanisms, and interoperability standards. One of the central components is the DCMF Process.

8.2 Functional Requirements of the DCMF Project

Based on the overall objectives and goals for the DCMF project, we can list some of the main functional requirements and design criteria for the proposed ontological knowledge base as follows: 236 8 Case Study II: The Defence Conceptual Modeling Framework Project

Handle unstructured information as input sources: The DCMF aims to capture and model domain knowledge related to military operations from a variety of sources. Sometimes, it could be Subject Matter Experts and deep interviews. It could be based on field reports sent in by military organizations. It could be other intelligence systems or Information Systems; it could be a video clipping or news coverage. Thus, the first level of domain interaction is basically a set of scenarios. These scenarios need to be examined and we treat them as the raw, unstructured data input to our DCMF Process. Flexibility and Adaptability: Flexibility and adaptability are required since the ontology should evolve based on the analysis of individual military operations scenarios. And not every scenario has a common thread running through them, so the concepts extracted from each may differ, may be incomplete, sometimes supplementary concepts may be available from another scenario and so on. The important issue is that the current ‘evolving’ ontology itself acts as a benchmark or lexicon to compare and start the knowledge extraction process from each new scenario. Thus, the ontology needs to provide input to the scenario analysis in one hand, and on the other hand, also needs to grow (take in) new information. Reuse (Based on) existing knowledge base and information: A lot of existing information pertaining to military operations or related fields has already been captured and modeled in different formats. Existing knowledge bases and ontologies should be reused and integrated. Several military operations related knowledge have also been standardized, such as the MIP’s JC3IEDM (Joint Com- mand Control and Communications Information Exchange Data Model). Interoperability: We should be able to interoperate/integrate with other Military modeling and simulation applications. The Simulation Models build on the conceptual models, which in turn are based on the proposed ontological knowledge base. Therefore, the simulation models and the DCMF-O should be able to interoperate with each other not only at simple data exchange level, but also at higher conceptual, strategic and tactical level. Rapid and Easy Development: It should be a fast and easy methodology, since most of the designers and analysts would not be ontology experts. Formal as well as Informal Representation: The proposed DCMF-O is aimed to be used by different target users. On one hand, it should be meaningful and give valuable input to high level decision makers and commanders in their strategic planning of operations. On the other hand, the Military Simulations designer and developer should get enough detailed information, to enable him to implement the same MSM directly in to a simulation model. Thus, there is a need for the DCMF- O to be represented as informal easy to understand UML class diagrams as well as formal machine readable, OWL representations. 8.3 The DCMF Process 237

Credibility, Authenticity to be verifiable, validated: Given the nature of this domain, the requirement for the DCMF-O to be credible, authentic is self- evidentiary. Thus, the DCMF-O concepts should also model the degree of credibility, authenticity of source etc. In short, the ontology should be readily verifiable and validated. Action Centric Model: Unlike other domains for ontology building, which are ‘object-oriented’ or centered around the concept of ‘objects’ and things that revolve around them,the military operations domain is action-centric. That is, the central concept of interest to us is the action or activity that is occurring. The supporting concepts answer questions like – why is this action happening? Who is doing it? What is needed to counteract this? Static and Dynamic Aspects: This requirement is related to the one above, action centric. Any military operation scenario involves objects which have some constant attributes, for example, a jeep has always four wheels; and there are some dynamic variables, for example, the rifle could be currently loaded with only two cartridges. While this temporal distinction of characteristics is not that vital for object centric modeling approaches, the same assumes important dimensions in this case where action-centric modeling is required. Consistency: Each military scenario could be analyzed by different subject matter experts as well as different ontology experts. However, the end result should be the same no matter who performs this transformation process. In other words, the ontology should be so designed along with required mapping rules and guidelines that the analyzed output, MSM derived should always be consistent as well as repeatable.

8.3 The DCMF Process

As per the stated goals and objectives above, the DCMF Process aims to distill knowledge from the military domain and structure it according to a given purpose, model and represent it in some reusable knowledge. To achieve this, we have analyzed several state of the art knowledge extraction, analysis, representation and modeling tools, methods and techniques. In the ongoing DCMF Project, we have found that no single tool, development methodology or technique meets all our functional requirements or the goals. Hence, we have made a blend of methods and tools suited to our specific military modeling and simulation domain. The underlying foundation is what we call the ‘DCMF Process’ by which one can iteratively process raw unstructured data or information and obtain structured knowledge as the final product. In this section, we briefly summarize the DCMF Process that has been presented in this DCMF Project. We refer the interested reader to a series of technical reports and articles published describing the same in detail (Mojtahed et al. 2005). It is to be noted 238 8 Case Study II: The Defence Conceptual Modeling Framework Project that the author of this thesis has not been the main contributor of the DCMF Process to be described below, but it has been summarized here for providing the readers with relevant background information to the DCMF- Ontology section, where the author has been active. There are four main phases in the DCMF Process that follow from the knowledge collection to the ultimate users who make use of the proposed conceptual models. The four phases adopt the traditional knowledge management life cycle, viz:

• Knowledge Acquisition (KA): The ﬁrst phase, KA has two main objectives. First, to put forward a set of requirements for the expected output, for a speciﬁc purpose. Secondly, the KA aims to collect the relevant information and data from different heterogeneous sources. • Knowledge Representation (KR): In this second phase, we begin to analyze the information collected and to process it as per the required output format. • Knowledge Modeling (KM): In this third phase, the knowledge analyzed and collected from individual scenario incidents, is generalized to obtain a generic knowledge model that could be reused in situations describing similar scenarios. • Knowledge Use(KU): Finally, the generated knowledge components, as they are now called, are put to use in targeted applications.

Each of these above mentioned phase consists of a number of sub-phases which may be iterated. Each of them make use of certain inputs, methods, tools and there are intermediary outputs available as well. We also identify different roles of the people involved in this DCMF Process.

8.4 Role of Ontology in DCMF

As stated by Mojtahed et al. (2005), we uphold the meaning of an ontology in the context of DCMF as:

An ontology is an explicit formal conceptualization of a shared understanding of the domain of interest including the vocabulary of terms, semantics as well as their pragmatics.

Note that we have included and stressed on two additional aspects, namely semantics of vocabulary as well as pragmatics. By semantics, we mean that the intended meaning of the text or natural language being analyzed should be taken in to consideration. By Pragmatics we mean that the implicit intent, context of the domain should also be made explicit. For example, the commanders belief or the enemy’s intent and motives should also be made apparent. We have used ontologies in the DCMF context as a knowledge base and conceptual analysis patterns. 8.5 Using the O4IS Design Methodology and USP2 Design 239

• As a look up lexicon and guide for the na ´ıve designer in the analysis and modeling phases. • As a knowledge base for storing, retrieving knowledge in the representation and use phases.

As a knowledge base, the DCMF-O requires to support inferencing and other advanced information retrieval. Some examples for targeted applications of such ontologies are:

• To organize military operative knowledge in conceptual spaces. • To support automated or semi automated tools for maintenance and knowledge discovery in different simulation based applications. • To support inferencing aided applications like expert systems, decision support systems, situation awareness for military operations planning and control.

8.5 Using the O4IS Design Methodology and USP2 Design

Keeping in mind the DCMF requirements,we began our research with an extensive literature study and analysis of current state of the art design methodologies in On- tology. Some of them have been reviewed and summarized in 3.8. Though many methodologies and approached for the design and development of ontologies have been proposed we ﬁnd many practical hurdles in applying any one of them constructively to suit the DCMF Project needs. As discussed by Kabilan & Mojtahed (2006b), we summarize some of the key issues as:

• One issue has been that ontologies are proposed to be domain independent generic conceptualizations of the world as it is. Therefore most of the ontology design methodologies proposed are generic and intended mostly for knowledge capture and representation of the domain under consideration, starting from scratch. Though these methodologies are all based on the experiences of the researchers from the ontology building exercise in particular domains, they have hesitated from involving any domain speciﬁc design constraints or functional requirements in their design methodology. • Another issue is that ontology is usually designed to capture and model the static concepts and their established relationships. However, a military simulation conceptualization needs that the procedural aspects or the state of affairs for planning a course of action be also captured and modeled cohesively with the intrinsic domain knowledge. • A third issue is that no existing ontology design and development methodology addresses the need for semantic interoperability between ontologies even at design time. That is, we contend that we need to consider at design time, the 240 8 Case Study II: The Defence Conceptual Modeling Framework Project

requirements of the targeted application like ﬂexibility, extensibility, reusability, traceability as well as interoperability with other military applications.

The above stated issues have been some of the motivating guidelines for our O4IS design methodology as we have seen earlier. We believe in re-use and sharing of knowledge and methods, so we have proposed a blend of existing design methodologies to suit our project needs and goals. As we have seen the DCMF Process is visualized to consist of four main phases. In the Knowledge Acquisition phase, the DCMF goal is to produce a set of requirements, a purpose and identify sources of information, targeted users as well as experts who will be the source of information. These are similar to what we have described in our ten step design methodology, guidelines 1 and 2, namely to establish the scope of the domain and the establish the targeted users, functional requirements, etc. The difference is that the DCMF process explores and establishes the scope of the entire targeted military modeling and simulation context, and will establish the functional requirements as per the entire targeted application; While in our design guideline, we aim to establish the context and purpose pertinent for the design and development of our ontology. Following our O4IS design methodology, the following design choices were made:

• G1: Establish the scope of the domain. The scope is that of military operations, speciﬁcally focusing on the actions and events, how they are to be countered, what resources are needed, who is responsible for the operations and so on. The limitation is that we do not (at the moment) concern ourselves with technical details or, details regarding other organizational, aspects of the military scenarios. • G2: Establish the targeted users, applications, and functional requirements. The DCMF project has a number of targeted users and applications. On the top level, it targets commanders and decision makers who need to plan and execute military operations. On another level, it targets military simulation modelers who need to have the conceptual models to be incorporated in to military simulations. On yet another level, the DCMF project targets other similar military modeling and simulation applications that need to interoperate. • G3: Choose ontology architecture: physical and logical. Currently the project is still in research phase and most of the ontologies are only proof of concepts. Hence, for the moment we have chosen a single ontology architecture as the physical ontology architecture. However, in the future, when we have other applications and ontologies to interoperate, we may migrate to a hybrid ontology architecture, where we would have a common ontology at the center and each application would have their local contextual ontology. 8.5 Using the O4IS Design Methodology and USP2 Design 241

• G4: Choose ontology development approach. As suggested in our O4IS design methodology, we choose the middle out design approach. Since, we base our domain ontology on an existing data mode, the middle out approach is further motivated. • G5: Choose level of ontology representation. As we have identified in G2, we have a wide range of targeted users and different application purposes. Hence, we have followed the Dual Conceptualization Representation as recommended in the O4IS design methodology. Our first set of ontology models are represented using UML conceptual models. Thereafter, we formalize them using OWL for supporting the machine-to-machine interoperability. • G6: Choose knowledge acquisition methods and tools. In the DCMF project different forms of knowledge acquisition techniques and tools have been evaluated. Currently, we are supporting only manual knowledge extraction and mapping using our proposed Semantic Analysis Representation. But, our ongoing work in this project also focuses on semi-automatic support for knowledge extraction. • G7: Knowledge analysis- Conceptualize the domain ontology. We conceptualize the domain ontologies following the USP2 Design and the SARs. We also follow the recommended dual conceptual representation and therefore our first artifacts are UML conceptual models. • G8: Knowledge representation:- Implement the domain ontology. We have implemented all the ontology using Protégé Ontology editor. • G9: Evaluate, assess and verify the domain ontology. The military domain has different standards and methods for verification, validation and accredition of the conceptual models. Our long term plan is to adhere to those recommendations and strategies. Currently, we assess the conceptual models and ontologies with the domain experts only. • G10: Use, maintain and manage the domain ontology. As we shall see later, we have begin work on proof of concept demonstrations of applications that use the proposed ontologies. On the issue of maintenance and management of ontologies, we have not yet reached that phase.

As we see one of the main components in the DCMF process is the DCMF- Ontology suite. And we shall see how we have used our proposed design methodology while designing this DCMF-O. In order to do this, we begin by examining the role that ontology has to play in the context of the DCMF Project. 242 8 Case Study II: The Defence Conceptual Modeling Framework Project

8.6 Defence Conceptual Modeling Framework- Ontology Suite

In the following sections we shall see the different ontologies that we have proposed for different contexts, namely the DCMF-O as a set of ontologies for describing the military domain concepts that adopts our proposed multi-tiered ontology architecture as discussed in the O4IS earlier. The structure is as shown in ﬁgure 8.2.

Fig. 8.2. Defence Conceptual Modeling Framework-Ontology Suite

DCMF-O comprises of three vertically aligned layers of ontologies:

• Upper Ontology Layer: Suggested Upper Merged Ontology (SUMO) from IEEE has been used as the top level generic conceptual layer. This layer has been used to tie down the do-main oriented concepts into more abstract real world concepts like entity, time, space, etc. • Middle Ontology Layer: The middle layer is intended to provide specialized domain concepts from the military operations and modeling domain. However, we have chosen to adopt the established standard JC3IEDM data model as a basis for the middle level. • Domain Ontology Layer: Finally, we have a bottom layer of speciﬁc and focused scenario/application ontologies like the Swedish Defence Organization ontology, weapons of mass destruction ontology, terrorist ontology and vessels etc.

For the current research, we do not focus on this set of template ontologies. We review the Upper and Middle ontology in the following two sections.

8.6.1 SUMO as the Upper Ontology

SUMO is an upper ontology that has been proposed as a starter document for the SUO WG (Standard Upper Ontology Working Group), an IEEE-sanctioned working group of people from the fields of engineering, philosophy, and information science. The SUO WG is developing a standard, i.e., the Standard Upper Ontology that will 8.6 Defence Conceptual Modeling Framework- Ontology Suite 243 specify an upper ontology to support computer applications in areas such as data interoperability, information search and retrieval, automated inference and natural language processing. According to Niles & Pease (2001), it is estimated that SUO will eventually contain between 1000 and 2500 terms and roughly ten definitional statements for each term. As mentioned above, SUMO has been a starter document and it is still in the development phase. The most recent proposed version is 1.72, proposed in December 2004. SUMO is designed to be relatively small so that assertions and concepts will be easy to understand and apply. Currently, the ontology consists of approximately 4,000 assertions (including over 800 rules) and 1,000 concepts. The knowledge representation language for the SUMO is the SUO-KIF (Knowledge Interchange Format) which is a predicate logic. The ontology can be browsed online, and source files for all of the versions of the ontology can be downloaded from IEEE’s website 2. The structure of SUMO’s top level concepts is illustrated in figure 8.3. The root node of the SUMO is ‘Entity’, and this concept subsumes ‘Physical’ and ‘Abstract’. The former category includes everything that has a position in space and time, and the latter category includes everything else. Physical entities are further divided into ‘Object’ and ‘Process’.

Fig. 8.3. The Top Level Concepts in SUMO

Other general topics covered in the SUMO include: structural concepts such as instance and subclass; general types of objects and processes; abstractions including set theory, attributes, and relations; numbers and measures; temporal concepts, such as duration; parts and wholes; basic semiotic relations; agency and intentionality.

2 http://www.ontologyportal.org/ 244 8 Case Study II: The Defence Conceptual Modeling Framework Project

In addition to the SUMO core upper ontology, SUMO is also associated to a Mid- level Ontology 3 and a set of domain ontologies. These domain ontologies include:

• Communications. • Countries and Regions. • Distributed computing. • Economy. • Finance. • Engineering components. • Geography. • Government. • Military. • Transportation. • World Airports.

8.6.2 JC3IEDM as the Middle Military Domain Ontology

The main source of information and the basis for the ontology design and development is the MIP (Multilateral Interoperability Programme) 4 proposed standard JC3IEDM (Joint Command Control Communication Information Exchange Data Model) 5. The MIP aims to provide an assured capability for interoperability of information to support joint military operations. Interoperability is not envisioned merely at a data level but also at strategic, operational and tactical level to allow proper planning and functioning of joint operations. As this objective of the MIP is well in line with the goals of the DCMF project, the proposed JC3IEDM was also found to be appropriate standard to base our ontological knowledge base representation. The purpose of the JC3IEDM, listed as an extract from the speciﬁcation states:

• A description of the common data in the JC3IEDM that contains the relevant data, abstracted in a well structured normalized way that unambiguously reﬂects their semantic meaning.

3 MILO ontology also written in KIF. Is available online at http://sigmakee.cvs. sourceforge.net/*checkout*/sigmakee/KBs/Mid-level-ontology.kif 4 The Multilateral Interoperability Programme (MIP), Home page: www.mip-site.org last accessed on 2006-03-03 was established by the Project Managers of the Army Command and Control Information Systems (C2IS) of Canada, France, Germany, Italy, the United Kingdom and the United States of America in April in 1998 in Calgary, Canada. The aim of the MIP is to achieve international interoperability of Command and Control Informa- tion Systems (C2IS) at all levels from corps to battalion or lowest appropriate level in order to support multinational (including NATO) combined and joint operations and the advancement of digitization in the international area. The MIP solution enables C2IS to C2IS information exchange and allows users to decide what information is exchanged, to whom it ﬂows and when. 5 Homepage of MIP. http://www.mip-site.org/MIP_Specifications/Baseline_3.0/ JC3IEDM-Joint_C3_Information_Exchange_Data_Model/Accessed: 2006-03-03 8.6 Defence Conceptual Modeling Framework- Ontology Suite 245

• A base document that can be used as a reference for future amendments to the model. • A core upon which nations can base their own modeling efforts of chosen areas and onto which specialized area models can be attached or “hung”. • A basic document that nations can use to present and validate functional data model views with their own specialist organizations. • A specification of the physical schema required for database implementation. The specification document along with its several annexes is well over 1000 pages long. The specification is technically well documented, with detailed explanations, models and notes on each component of the data model. It would be tedious to list all of its salient features here. Therefore, we list a few of the main concepts and refer the interested reader to the main JC3IEDM specification document. There are three models that are presented in the JC3IEDM namely the conceptual, logical and physical: 1 The Conceptual Data Model represents the high level view of the information in terms of generalized concepts such as actions, organizations, material, personnel, features, facilities, locations and the like. This model is of interest to senior commanders wishing to verify the scope of the information structure. 2 The Logical Data Model represents all of the information and is based upon breaking down the high level concepts into specific information that is regu- larly used. For example, a tank is an armored fighting vehicle that is a piece of materiel. This breakdown follows human reasoning patterns and allows command and control systems to generalize by recognizing, for instance, that tanks are equipment. A logical data model specifies the way data is structured with an entity-attribute-relationship diagram and supporting documentation. This model should be of interest to staff officers to ensure that the operational information content is complete. 3 The Physical Data Model provides the detailed specifications that are necessary to generate a physical schema that defines the structure of a database. It is of primary concern to C2IS system developers building JC3IEDM-compliant systems.

Understanding the JC3IEDM

The JC3IEDM has been setup to fulﬁl the following requirements: 1 There is a need to describe objects of military signiﬁcance. Objects of interest refer to physical things like units, equipment, materiel, personnel. Also non- physical concepts like location, co-ordination points. 2 Individual objects need to be differentiated from a particular are type of objects. Also there should be a way to identify groups of individual objects. 246 8 Case Study II: The Defence Conceptual Modeling Framework Project

3 Objects should be identiﬁed by sufﬁcient characteristics as is required for command and control tasks. 4 There should be means to display operational status and situations as represented by facts of the objects. 5 There should be means to record and maintain historical log records of objects and other dynamic information as information packages. 6 There should be means to record activities of the objects.

From the perspective of the DCMF project, we had similar requirements as recapitu- lated below:

• To describe a MSM, one needs the same concepts of Objects or Entities of interests around which the operation is focused. • Each entity has both static characteristics as well as dynamic properties, as is represented by the situation concepts in the generic hub. • The central focus in an MSM is around activities, or Actions as proposed in the generic hub as well. • There is a need to co-relate pieces of information, to provide the context and other vital information, a group of information packages is required as well.

Fig. 8.4. Main Concepts of DCMF-O: Adapted JC3IEDM

Basic concept in data specification is an entity, i.e. any distinguishable person, place, thing, event or concept about which information is to be kept. Properties or characteristics of an entity are referred to as attributes. The entire structure is generated from 15 independent entities that is, entities whose identification does not depend on any other entity. We explain the principal concepts given in figure 8.4 above by explaining their intended use or the purpose for defining them. We leave 8.6 Defence Conceptual Modeling Framework- Ontology Suite 247 the interested reader to refer to the JC3IEDM specification for a precise technical explanation. Objects have been defined as belonging to a particular type Object-Type or as an individual Object-Item. Object Types are generally static and persistent, whereas individual Object Items are dynamic and most likely to change over time. For example a characteristic of gun like calibre, main track width, and load class etc are attributes of Object-Type whereas, actual fuel contained, ammunition left, current operational status of a tank are characteristics of Object Item. Both Object-Type and Object-Item are further classified in to extensive hierarchies. We chose to implement all the second level of classification. Further on, we chose to model only relevant categories and sub categories. The rest are left for future work. Our current proof of concept implementation supports over 1500 concepts from the JC3IEDM. An object must have the capability to perform a function or to achieve an end. Thus, a description of capability is needed to give meaning to the value of objects in the sphere of operations. It should be possible to assign a location to any item in the sphere of operations. In addition, various geometric shapes need to be represented in order to allow commanders to plan, direct, and monitor operations. Examples include boundaries, corridors, restricted areas, minefield and any other control measures needed by commanders and their staffs. Several aspects of status of items need to be maintained. The model must permit a description of the composition of a type object in terms of other type objects. Such concepts include tables of organizations, equipment, or personnel. The model must reflect information about what is held, owned or possessed in terms of types by a specific object item. (Situations - establishments, holding, association etc) There is a need to record relationships between pairs of items. Key among these is the specification of unit task organizations and orders of battle. The model must support the specification of current, past, and future role of objects as part of plans, orders and events. The same data structure should be used to record information for all objects, regardless of their hostility status. Provision must be made for the identification of sources of information, the effective and reporting times and an indication of the validity of the data. So far, the description of the basic concepts matches with the expected conceptual model for military operations domain. And as previously stated the JC3IEDM has been developed through a consensus of several nations, part of the MIP. Thereby, the validity of these primary concepts is self-established. However, being a data model the JC3IEDM has some limitations on being used as an ontology as-is. We have discussed some of the limitations of JC3EIDM in (Kabilan & Mojtahed 2006a). One of our ongoing tasks is the migration of data models into ontologies, the methods, approaches and pros-cons. 248 8 Case Study II: The Defence Conceptual Modeling Framework Project

With this we conclude the overview of the proposed DCMF-O. In the next sections, we shall look at some of the scenarios that we analyzed using the DCMF- Process and the DCMF-O. Without going too deep into the analysis, we shall look at the use of ontologies and some results.

8.7 Customizing Semantic Analysis Representations for Military Scenarios

We begin applying our USP2 Design analysis by identifying the entities and concepts of the given scenario. We describe the scenarios in natural language text from video clippings, interviews with domain experts etc. We use the the ER model to identify the events, actions and the resources. The resources in this particular domain are artifacts or objects. Having identified the main actors, and objects, we next apply our Performative verb ontology (section 6.4), to identify the specific performance that is occurring. We use this later in our procedural and pragmatic analysis of the scenario. The performative action identified gives us the nature of the action:- if its assertive, commissive, directive, declarative or expressive. Based on this we can analyze further with our ECA rule ontology or the Deontic Analysis Model. ECA Rule ontology is useful for situations where the actions are directives. Deontic Analysis Model are useful for modeling commander’s intent, expected outcomes, as well as orders. Hence it could be for expressives, declaratives or directives. Once we have identified the entities and grouped them into actors, actions, and artifacts, we are ready to begin the semantic relationships analysis as suggested by step 3 in our Semantic Concept View. As we have discussed in section 6.3, we have adopted Storey’s classification of semantic relationships at different levels. In section we have proposed a set of semantic relationship patterns for the local context of Storey & Purao’s (2004) classification. In this case study, we have further specialized these relationships for the specific military domain as described below:

• Prescriptive Relationships: We have proposed the ECA rule ontology as a conceptual design pattern for capturing the prescriptive and normative behavior of a domain. In this case study, we apply them to speciﬁc rules of engagement that are prescriptive norms for the expected behavior of military operations. More like doctrines for code of conduct. To help the domain experts in analyzing the individual Rule of engagements, we have further mapped the DCMF-O concepts to the proposed ECA rule model. In section we present these ‘global context’ for the ECA rule prescriptive relationships. We also present a discussion of the user evaluations done in this context. Thus, the proposed ECA rule ontology has been used as analysis patterns as well. 8.7 Customizing Semantic Analysis Representations for Military Scenarios 249

• Structural Relationships: In structural relationships, we have seen the associations between , or type of relationships. Based on the military domain, we have identified specific verb associations that have specific connotation in the military domain. • Functional relations: We have identified and proposed some patterns for functional relationship identification in section 6.5.2. • Temporal relations: The temporal relationships (section 6.5.3) presented earlier have also been used in this case study without any further need for domain specific mappings. • Deontic Relationships: We have been able to apply the proposed DAM (section 6.5.4) without the need for any further domain specific specializations.

Hence, we now only discuss the global contexts deﬁned for the Prescriptive and structural relationships.

8.7.1 Global Context ECA Rule - Prescriptive Relationships

We have earlier proposed a set of conceptual analysis models for analyzing and capturing the semantics of different kinds of relationships. One of them being prescriptive behavior in the form of ECA Rule Ontology.(refer section 6.5.6). Following Storey and Purao’s classification levels (figure 6.4), we now specialize the proposed ECA rule ontology by mapping to military domain concepts. We map the concepts from our DCMF-O to the ‘what’, ‘why’, ‘where’, ‘when’ associations identified in the ‘event’ and‘action’ concept of the ECA rule ontology. In the military domain, an event is usually an unplanned activity and is perpe- trated by enemy forces. Similarly, we extend the action concept. For the condition concept, we include aspects of preconditions, post conditions, dependencies etc. The Rule of Engagement is a prescription of expected and allowed military behavior in the case of described events happening. To further aid for Military domain expert users in their analysis work, we mapped the ECA Rule Ontology to a military operations ontology, Defence Conceptual Modeling Framework Ontology ((Kabilan & Mojtahed 2006b)). For example figure 8.5 shows the mapping of ’who’ concept to DCMFO concepts. Similarly figures from 8.6 to 8.8 show the other mappings. In our proof of concept demonstration, this is provided as a lexical help for the user making the analysis and subsequent knowledge representation. The case study analysis provides the assessment and evaluation done on the ECA rule ontology as well. 250 8 Case Study II: The Defence Conceptual Modeling Framework Project

Fig. 8.5. Example of mapping 5Ws and the DCMFO

Fig. 8.6. 5Ws-What mapped to DCMFO

Fig. 8.7. 5Ws-Why mapped to DCMFO 8.7 Customizing Semantic Analysis Representations for Military Scenarios 251

Fig. 8.8. 5Ws-When mapped to DCMFO

8.7.2 Military Behavior Analysis- ECA Rule Ontology

Military activities are regulated by different rules and guiding procedures. One of those are Rules of Engagement (ROE) which are directives designated to regulate situations and limitations for when force may be used. ROE reflect political and diplomatic constraints and should be set at high general level. A ROE defines the constraints for a certain military activity, what is forbidden and what is allowed for the specific activity during certain circumstances. Examples of such activities are use of force, detention of civilians, use of land mines, use of warning shots, and prevention of crimes. The aim of using ROE is threefold. The political aim is to guarantee that military operations are implemented to support the policy of the political management. The military aim is to guide commanders to solve conflicts. Finally the legal aim of ROE is to guarantee that military operations are implemented within the limits of national, international and human rights. The ROEs used in this case study has been taken from a fictitious scenario used for experiments and exercise in the Swedish Defence Forces. The scenario contains a multinational operation with the end state goal to implement a signed Peace Agree- ment in an area with many years of ethnical and religious conflicts. A collection of ROEs taken from this scenario have been used for our analysis and case study. Fig. 8.9. Illustration of a Rule of Engagement analyzed using ECA Rule Ontology 8.7 Customizing Semantic Analysis Representations for Military Scenarios 253

The ROE was used as input information to the phase Knowledge Representation in the DCMF process and analyzed with the method Five Ws. In previous work, we used the Five Ws to analyze a sequential scenario giving the result that it is feasible but much of the context was lost (Mojtahed et al. 2005). This time we were interested in analyzing rules with Five Ws but also to retain the contextuality after the analysis and representation process.

Table 8.1. Sample Rules of Engagements ROE 1: The use of minimum force to prevent any attempts by persons to prevent the BFOR from discharging its duties is permitted. ROE 2: The use of minimum force to defend friendly forces and persons with designated special status against hostile action is permitted. ROE 5a:The use of minimum force to prevent the taking possession of or destruction of property with designated special status is permitted. ROE 5b:Individual service personnel are to be informed when they are protect- ing speciﬁc property on this basis.

The selected ROEs were analyzed with Five Ws in order to study feasibility of analyzing rules with this method and how to keep the context after analysis. The result showed that it is feasible to analyze ROE with Five Ws but it is not really satisfying since there is a loss in information and context which affects the reusability. If too much context is lost during the process it is difﬁcult to reuse the analyzed information. One way of dealing with this is to ﬁll in the gaps with information and have a Subject Matter Expert verifying the extended information. Table 8.2 shows an extract from our analysis with only the 5Ws.

Table 8.2. Extract of Rules analyzed with only 5Ws No. WHO WHAT WHERE WHEN WHY A1 BFOR Is permitted to Joint Operations During imple- To prevent any Land use minimum Area (JOA) in mentation of attempts by per- Force force Bogaland UNSCR’s 2377, sons to prevent 2427, 2450 and the BFOR dis- Bogaland Peace charging its du- Agreement ties

Five Ws is useful on a conceptual level to get a quick categorization and understanding of an event. Using the Five Ws as a support for categorizing an event is feasible since it can contain the most important aspects of that event. The Five Ws analysis approach is a good start though but needs to be complemented with 254 8 Case Study II: The Defence Conceptual Modeling Framework Project rules. Now, we apply the proposed ECA rule ontology along with its mapppings to the 5Ws and military concepts (DCMFO). The same rules were analyzed as shown in table 8.3.

Table 8.3. Extract of Rules analyzed with ECA Rule Ontology ROE1 Event Condition Action A1 Attempts to dis- BFOR prevented use of minimum force charge of duties from discharging normal duty WHO Hostile forces (does – BFOR does it Hostile Forces are it) BFOR is affected affected WHAT BFOR is obstructed – Use of Minimum Force to Prevent or Defend WHEN Within peace keep- – Within peace keeping period ing period WHERE Bogaland – Bogaland WHY Terrorism in Boga- – Peace keeping in Bogaland land

As can be seen from the above, the information aggregated in table 8.3 has expressed more of the implicit knowledge than the 5Ws. The analyzed information was then captured and represented as an ontology using our ECA rule ontology. We have implemented the ECA Rule Ontology using the Web Ontology Language (OWL) and using the Protégé Ontology Editor (see figure 8.10). Furthermore, we have semantically enriched our ontology by mapping to a linguistic resource like Wordnet as also used earlier in section 6.4 and seen now in figure 8.11. Fig. 8.10. ECA Rule Ontology implemented in Protégé 256 8 Case Study II: The Defence Conceptual Modeling Framework Project i.8.11. Fig. lutaino C ueOtlg nihdwt WORDNET with enriched Ontology Rule ECA of Illustration 8.7 Customizing Semantic Analysis Representations for Military Scenarios 257

8.7.3 Global Context: Structural Relationships

We follow Storey & Purao’s (2004) proposal for the abstraction levels for semantic relationships. According to them, the third level– the Global Context describes the semantic relationships specific to the domain in which the relationship is used. We specify some such global contexts for our military operations domain. Again, we draw support from the JC3IEDM as our input model. Based on domain values and specifications provided, we have been able to extrapolate sets of valid semantic verb relationships for this domain. The structural relationships between two entities as identified earlier can now be grouped in to three different possibilities:

• Actor-Actor Structural Relationships: From the DCMF-O we have identiﬁed actors as organization or person. The actor-actor structural semantics describe the possible relationships that two actors or role players can have. Some of the possible semantic relationship patterns are listed in table 8.4.

• Actor-Action Structural Relationships: In the military domain actions and events are the central concepts. Each action or event must have some actor or role responsible for it, controlling it, executing it and so on. Some of these type of semantic relationships have been identiﬁed in table 8.5.

• Actor/Artifact - Actor/Artifact Structural Relationships: The third type of structural relationships refer to possible associations between actors and material artifacts. As discussed earlier, actors are those capable of performing an action independently and artifacts are those that are used, produced, consumed in an action. They may also be locations and geographical features or political boundaries where the action is said to occur. Some examples of possible relationships is shown in table 8.6. 258 8 Case Study II: The Defence Conceptual Modeling Framework Project

Table 8.4. Actor/Role-verb-Actor/role Structural Relationships Entity1 Entity2 Relationship Explanation Organization Organization has assigned Organization1 has assigned resources, personnel and task over to organization 2 Organization Organization has captured Organization1 has captured forcefully organisation2 Organization Organization has detached organization 1 has a part of itself as organization 2 separated from the main organization at some other location Person Organization has full command of the military authority and responsibility of a superior officer from within the military organization who has full command and control over given organization. Organization Organization plays-the-role-of Organization 1 plays the role of organization 2. Person /Role Person /Role has operational com- the authority granted to a command of mander to assign missions or tasks to sub-ordinate commanders, to deploy units, to reassign forces and to retain or delegate operational and/or tactical control as may be deemed necessary. Person /Role Person /Role has operational con- role has operational control of trol of the authority delegated to a commander so that the commander may accomplish specific missions or tasks which are usually limited by function, time or location; to deploy units concerned, and to retain or assign tactical control of these units. It does not include authority to assign separate employment of the components of the units concerned. Organization Units has attached temporary placement of units in an organization Table 8.5. Actor/Role-verb-Action Structural Relationships Entity1 Entity2 Relationship Explanation Organization action approves Organization authorizes action Organization action controls specified organization is in charge of the direction, co- ordination, execution of a specified action Organization action Initiates starts the planning or execution of the action Organization action is-coordinating- organization is responsible for agent-for coordinating the action when two or more resources are involved. Organization action is-interested-in the specific organization takes an interest in the specified action Organization action is-liaison-for denotes the organization that acts as the liaison for the specified action Organization action is-point-of-contact- denotes the organization that is for to be contacted in connection with the specified action Organization action plans the organization that performs the detailing of the specified action Organization action observed the organization that has wit- nessed the execution of the specified action Organization action requests the specific organization that indicates requests for a specific action. 260 8 Case Study II: The Defence Conceptual Modeling Framework Project

Table 8.6. Entity-verb-Entity Structural Relationships Entity1 Entity2 Relationship Explanation Organization Facility administers organization is responsible for the administration of the facility Person Person augments person 1 extends the capability of person 2 in his tasks. Organization Materiel consumes organization expends the object materiel Materiel Materiel contains Ex.The bag contains the paper. Organization Facility coordinates-the-use- the organization arranges the of scheduling of the facility Person /Or- Person /Organi- employs Entity1 is the the temporary or ganization zation /Facility permanent user of entity2. ex: /Facility The university employs teachers. Person Person exploits Person 1 takes advantage of person 2. Organization Person has-as-a-member ex:The student union has as members students Control Fea- Control Feature intersects ex: 5th Cross stress intersects ture with the Highway E14. Organization Materiel installs ex:System Administrator installs /Person new security software. Facility Meteorological is affected by ex: Our Stockholm Headquarters Feature is affected by hailstorms. Person Person is-aunt-of a family relationship between two persons, where person 1 is a female, and is the sister of per- son2’s parents. Facility /Or- materiel is-authorized-to indicates formal entitlement. ganization ex:The Police are authorized to /person use speed cameras. Organization Organization is-captor-of ex: Terrorists are captor of the /person /person Beslan School. 8.8 Case Scenarios 261

8.8 Case Scenarios

So far, we have discussed how we have used the O4IS design methodology in the DCMF. We now look at some of the military operations scenarios that we have applied our proposed ontologies to over the last three years. We present only the overview of them below. With each iteration our O4IS design methodology has been successfully tested and reﬁned following our experiences. We are constantly analyzing new scenarios in the ongoing project.

8.8.1 Scenario 1: The Kosovo Arms Smuggling Scenario

The chosen scenario simulation takes place in Kosovo in May 2002. A Swedish patrol from the Swedish peace keeping force discovers a looted weapons depot and report this into the information system. An intelligence officer in Sweden receives the report and starts a further investigation. Information from different sources leads to the estimate that the missing weapons might be smuggled to Sweden by organized criminals. Cooperation between different military and civil organizations to acquire information leads to the confiscation of the weapons in the harbour of Gothenburg in Sweden. The detailed specifics of the scenario are to be captured and modeled as part of a re usable ontology and thereafter also visualized as a series of procedure like components called the Mission Space Models. Figure 8.12 depicts the scenario as an use case. A textual description of the sequence of events was transcribed to be the input for our scenario analysis. An extract of the text is illustrated in table 8.7.

Table 8.7. Extract from Kosovo Scenario A Swedish patrol from a battalion in Kosovo finds weapons in the forest near a village called Janjevo. The finding is reported in the battalion’s intelligence report and this is tele-faxed in encrypted code to Stockholm. The information about the finding is received by command central at MUST and the report is registered in the System. The information about the found weapons is made available for the department of international intelligence (MUST International Depart- ment).

Using the Semantic Concept View, we identiﬁed the main concepts ( individuals) of interest in our given text. We used our proposed DCMF-O as our reference and conceptual model and the 5Ws as knowledge extraction method. We found that we had incomplete information in many cases and we had to revert back to our 262 8 Case Study II: The Defence Conceptual Modeling Framework Project

Fig. 8.12. MUST Kosovo Arms Smuggling Scenario 8.8 Case Scenarios 263 subject matter experts (domain experts) for iterative knowledge acquisition. At the end, we had identiﬁed the concepts in our scenario to terms used in our DCMF-O. An illustrative extract is shown in table 8.8:

Table 8.8. Semantic Analysis Extract for Kosovo Scenario Comp. Ques. Natural Language Text Concepts identified in DCMF-O Who Patrol from Swedish con- Patrol: Military Type tingent KS05 Organization(under govt type object-type: Unit-Type: has Affiliation object type relation to Swedish Contingent: Object-Item-Group. Swedish: affiliation What Patrolling Patrolling: action-task purpose:WHY AOI: Location When From 1st may to 31st Reporting-Data: time May 2002, Why To secure the AOI(Area Action-Objective, Con- of Interest) text Where AOI somewhere in AOI: specification detail Kosovo AOI is both a Location as well as a CONTROL FEA- TURE: may even be a sub type of control -feature like ROUTE etc

After the mapping, we implemented the same in our DCMF-O in Protégé. Thus, our ontology also acts as the knowledge base to store all analyzed scenarios. Following our Procedural Concept View analysis and using the BPMN-CWM patterns as proposed earlier (for the other case study), we derived the procedural sequence of actions that occurred in our Kosovo case scenario. The Procedural Con- cept View for this scenario may be seen in figure 8.13. As we can see, we were able to apply the USP2 Design as a knowledge analysis method as well. We used our DAM (Deontic Analysis Model) to get the Pragmatic Concept View as illustrated in figure 8.14. Our experiences at the end of this scenario revealed that:

• Our DCMF-O designed using the O4IS design methodology was correct to the most part. We identiﬁed missing links in the ontology. Some of these were due to 264 8 Case Study II: The Defence Conceptual Modeling Framework Project

inherent gaps in the original JC3IEDM data model itself. For the next iteration, we planned to extend and modify the DCMF-O further. • Our USP2 Design approach was useful not only in the design phase of DCMF-O but also in the use and subsequent population of the ontology. • Though we had proposed the CWM-BPMN patterns originally for the contract domain, we found that with little modiﬁcations (mappings of the domain concept only) we were able to use them to deduce the procedural view of the military operations as well. This emphasizes that our proposed CWM methodology (Pro- cedural Concept View) can be re-used in different domains. Fig. 8.13. Procedural Concept View: using CWM 266 8 Case Study II: The Defence Conceptual Modeling Framework Project i.8.14. Fig. rgai ocp iw sn DAM using View: Concept Pragmatic 8.8 Case Scenarios 267

8.8.2 Scenario 2: The Viking Shield Example: Lord Barkan Hostage Simulation

The Lord Barkan Case Scenario has been adapted from the Viking Shield scenario. These scenarios are originally meant for military training and exercise purposes. The whole scenario is visualized as taking place in a fictitious country called Bogaland, which is geographically supposed to lie in parts of Gotland. The background for the international peace keeping operation is ethnic conflicts between two fictitious groups of local civilians. There are two rival ethnic groups both having access to paramilitary forces, economic support etc. They engage in drug and arms smuggling as well. One of them is headed by a local warlord called Lord Barkan. A joint peace keeping force is set in place to resolve the conflict amicably. A number of documents including some rules of engagement are available. Once again based on the video clippings and other background documents, a textual document was prepared as the base for the scenario analysis. An extract of the same is shown in table 8.9:

Table 8.9. Extract from Lord Barkan Hostage Scenario Warlord Barkan and paramilitary group Gute Rams has taken 2 BFOR soldiers as hostage. The hostage managed to escape during local fes- tivities (Lucia) when the guards were drunk. They escaped from the building were they were held and was later picked up by a police patrol and taken to hospital. Considering the circumstances they are in a good condition and will most probably be able to return to their fami- lies for Christmas. Mr Barkan Mida Warlord on Gotland does not have completely support from the people on Gotland. Opposition leader Aron Aronsson is interviewed. He knows where Barkan is keeping his supplies and hostage since it is a ‘small island’. If Aronsson is assured security support from BFOR he will give some information regarding Mr Barkan’s whereabouts.

For this case scenario, we used the Semantic relationships as described earlier to help us identify and match the concepts to our DCMF-O. We identify the main concepts, thereafter establish the functional and temporal relationships between identi- ﬁed actions. After having extracted the Semantic Concept View, we carry out the procedural and pragmatic analysis. We use the ECA Rule Ontology as our reference to analyze what is being done, who is doing it, what are the conditions under which this action or event has occurred. A visualization of this process can be seen in our DCMF tool demonstration as shown in ﬁgure 8.17. Fig. 8.15. Lord Barkan Hostage Scenario 8.8 Case Scenarios 269 Lord Barkan Hostage Scenario: Functional Relations Fig. 8.16. 270 8 Case Study II: The Defence Conceptual Modeling Framework Project i.8.17. Fig. odBra otg cnroPecitv eairAnalysis Behavior Scenario:Prescriptive Hostage Barkan Lord 8.8 Case Scenarios 271 Lord Barkan Hostage Scenario: Scenario Viewer Fig. 8.18. 272 8 Case Study II: The Defence Conceptual Modeling Framework Project

8.8.3 Scenario 3: The Moscow Theater Hostage Crisis

This case scenario is based on the real terrorist hostage situation that occurred in October 2003 at a theater in Moscow. 40 armed Chechen rebels took control of a theater during a performance and took 850 hostages. The actual sequence of events is described in figure 8.19. The gunmen were led by one Movsar Barayev who threat- ened to execute all hostages if his demands were not met. A videotaped statement was released and for three days there was a stand-off during which negotiations and reconnaissance mission was carried out by the Russian authorities. Several performers who were backstage at the time the coop took place managed to escape through some rear windows. They provided the military personnel with the first intelligence report about the number of hostages, the number of gun men, their weapons etc. Some hostages were executed who tried to escape. A couple of relatives who tried to enter the building from outside were also killed. Further intelligence reports were obtained from mobile phone calls from the hostages themselves. The rebels released few children and a sick man with a heart condition. Following three days of the seige, the Russian special forces carried out a covert military operation and stormed the theater. Though much of the actual events are not public, the outcome was that all terrorists were killed. Some of the hostages also died due to the nerve gas used. This scenario has been the most complex scenario that we have analyzed so far. The volume of information to be processed has been substantial. The scenario provided us with ample opportunity to test the extent and depth that our DCMF- ontology suite could successfully capture. Some missing concepts or their characteristics were also identified and the DCMF-O suitably refined. The scenario also gave us a huge number of action tasks and events happening in the same time space. We could also test our functional and temporal relationships between actions. Due to lack of space we do not discuss in detail our results here. One observation was that in the eventuality of long and complex scenarios, the visualization of the procedural aspect became tedious if we were to use only the graphical visualization of the OWL ontology itself. At the same time, our targeted end users, namely the military domain experts, felt that the decision makers do not need to see all the captured information at the same time. This led us to work on focusing on the visualization of only the action execution in a scenario. A related work designed and developed a tool called the Scenario Viewer (section 8.8.4) which can present the activities in a UML activity diagram. 8.8 Case Scenarios 273

Fig. 8.19. Moscow Theater Hostage Scenario: Military Operation 274 8 Case Study II: The Defence Conceptual Modeling Framework Project

8.8.4 Scenario Viewer- application for Knowledge Use

We have seen that DCMF-O in our Protégé implementation can be used for storing the scenario information. However, the graphical visualization facilities with the current Protégé implementation is not user friendly. For example, a commander may wish to view only the sequence of actions and events taking place. A UML activity diagram would suffice for this purpose without the need for irrelevant other information being displayed. Hence, a context sensitive information retrieval was necessary. A tool for such visualization has been developed as part of the DCMF project by Johan Persson (2007). We do not discuss the particular details of this work but refer the reader to the publication. The Scenario Viewer can connect to different domain ontologies and also makes use of some process based ontology for interoperability between the domain ontology and the application. The Scenario Viewer currently supports the option of visualization as UML activity diagram only. It is possible that in future we may build support for other formalizations like BPMN (Business Process Modeling Notation) etc. The UML activity diagram is automatically generated from the stored knowledge. Each activity or task on the UML activity diagram can be clicked on to view details of that action. Composite actions or sub processes may be clicked open to see further details. Sam- ple screen-shots of the Scenario Viewer has been seen above in our case scenario examples.

8.9 Case Study Results and Evaluations

Our proposed ontologies, the DCMF-O and the ECA Rule Ontology need to be assessed on different levels:

1 The formalization and ontological foundations: if they fulfill all the requirements of formal ontologies. 2 If DCMF-O and the conceptual analysis models proposed, like the ECA rule ontology fulfill the specific requirements of the DCMF project. 3 Practical applications, ease of use and utility from the end user’s perspective: Is the proposed set of ontologies as a knowledge base and a lexicon simple enough for non ontology experts to use in their analysis and simulation of scenario work?

For (1) and (2) we have carried out our assessment based on the theoretical foundations as discussed in chapter 3. The specific requirements from DCMF have been discussed in (Kabilan, De Nicola, Missikoff & Mojtahed 2006). Since our conceptualizations and design methodology (O4IS design methodology and USP2 Design) are based on current state of the art methods and guidelines, we assess that our proposed ontology models are stable. Since the implementations are only proof of 8.9 Case Study Results and Evaluations 275 concepts, we have not populated these ontologies with a large number of individuals(instances). Therefore, they cannot be termed as fully functional knowledge bases as they are of today. But, they can be easily filled in with these instances to create the required reusable knowledge base. On the (3) issue mentioned above, we have conducted a user perspective study on the ECA Rule Ontology. A selected group of Subject Matter Experts (domain experts) from the Swedish Defence Research Agency were chosen and they were given a task to analyze some rules from the Rules of Engagement document. The test group had knowledge of the military domain and experience of categorizing information. They were asked to categorize a couple rules using the simple 5 Ws method and later with the ECA rule ontology.Thereafter they were required to input these as individuals in our implemented ECA Rule Ontology in the Protégé ontology editor. After the domain experts accomplished the analysis and categorization,they were required to provide assessment and feedback on the following issues/ questions:

1 Ease of analyzing the ROE using Five Ws (on a scale 1-5). 2 Ease of analyzing the ROE using ECA rule ontology (on a scale 1-5). 3 What information do you think can be analyzed with Five Ws? 4 What information do you think could be analyzed with ECA Rule Ontology? 5 Have you used Prot´eg´e before? If yes, how would you rate that the ECA Rule Ontology, for analyzing ROE, has improved (on a scale 1-5), the following criteria: • Usability • Ease • Utility

For the first question, ease of analyzing with Five Ws, there was a mean answer of 3 (max= 4 and min=2). Analyzing with ECA rule ontology was considered to be easier with an average of 3.6 (max= 5 and min = 2). The domain experts felt that analyzing with only 5Ws was not satisfactory since contextual and implicit information was lost. Specifically in the case of Rules of Engagement, the rules do not explicitly predefine a ‘when’ or ‘where’ the rule may be applied. It depends on the situation and context. The assessment group answered that they would use the Five Ws to analyze information which described ‘sequences of events’, ‘scenarios already occurred in a certain order and a certain place’. On the question when to use the ECA Rule Ontology the test group had the view that the ECA rule ontology could be used in cases like description of rules which are not bound to time or location, instructions and general directives and so on. Hence, our basic intention to capture and model prescriptive behavior was fulfilled. 276 8 Case Study II: The Defence Conceptual Modeling Framework Project

The entire test group had seen or used the Protégé ontology editor prior to our interview.They rated an average of 4 on the questions regarding the actual ECA Rule Ontology implementation and interface built in Protégé.(on the account of usability (mean=3.8, max=5, min=3), utility (mean=4.0, max= 5, min=4) and ease (mean= 4.2, max= 5, min=3)). The users felt that the main advantages with the ECA Rule Ontology are:-

• Their analysis from natural language to knowledge representation became easier, since they had a help from the ontology and previous ‘instances’ to look up. • they could do the analysis from natural language to ontology consistently. That is,even though all the users in our target group were non-ontology experts, and they all independently carried out the exercises, they all came up with similar results. • Since most of them were familiar with 5Ws analysis, the ECA which used 5Ws as well, was easy to comprehend and adopt

However, the users also felt that the ECA Rule Ontology was not covering all the semantics of conditions and all possible relationships to event and action. We consider this to be an useful input and hope to improve our model in the next iteration. With that we come to the end of this case study discussion. It is to be noted that this is an ongoing project and is estimated to continue for another three years or so. That implies that we would be iterating through the ontology design, building and use. We have not described the domain or the analysis done in as much detail as for the ﬁrst case with business contracts. However, our overview and results displayed are indicative of the use of O4IS design methodology and USP2 Design. We have also demonstrated the utility of our Semantic Analysis Representations as reference patterns to be used by end users of targeted applications as well as the Information Systems designers. To wrap up this chapter we list some of the salient contributions of this case study so far:

• The DCMF-O has put forward a reusable knowledge source. • Our analysis and transformation of the JC3IEDM in to an ontology is now a part of an ongoing NATO task group that, among other things, shall also look at how different projects are adapting the JC3IEDM in to an ontology. • The analyzed scenarios and the ontology resource is to be implemented in applications that are underway. O 9

Discussion of Results

In this chapter, we now review and assess the results produced in this research. We shall carry out our evaluation and discussion at two levels. At the ﬁrst level, we review and assess the main artifacts produced in this research, namely the O4IS design methodology, the USP2 Design and Semantic Analysis Representations. We have already assessed the individual artifacts and contributions of the case studies in the respective chapters. At the second level, we evaluate our research itself based on the design science research guidelines.

9.1 Assessing the O4IS Design Methodology

In chapter 3, we have reviewed some of the current ontology building methodologies, namely: Uschold’s Skeletal Methodology; Gruninger and Fox’s Methodol- ogy; Methontology; Noy and McGuinness’ 101 Methodology; and UPON methodology. There exist several other ontology creation methodologies like: the DILIGENT methodology (Tempich, Pinto, Staab & Sure 2004); OTK methodology (Fensel, van Harmelen, Klein & Akkermans 2000); etc. A survey of some other relevant ontology- building methodologies has been carried out by Cristani & Cuel (2007). In this section, we shall compare our proposed O4IS design methodology with our surveyed ontology design methodologies (chapter 3), and highlight the advantages O4IS design methodology has over the others.

9.1.1 Surveyed Ontology Methodologies: A Recap

Some of the current state of the art ontology building methodologies, including those proposed by: Uschold & Gruninger (1996); Gruninger & Fox (1995); Noy & McGuinness (2001); Fernandez et al. (1997); and De Nicola & Missikoff (2005) have been surveyed in chapter 3. We brieﬂy recap the discussion on the different proposed methodologies for capturing the domain semantics: 278 9 Discussion of Results

• Uschold’s Skeletal Method: Uschold & Gruninger (1996) proposes a skeletal methodology that consists of four steps for the development of an ontology targeting the enterprise domain (Uschold et al. 1995). The methodology proposes: 1 Identifying the purpose which is important in order to establish the goal and aim of the intended ontology. 2 Build the ontology by capturing the knowledge, code this knowledge and integrate existing ontologies available. 3 Evaluate this ontology. 4 Document the ontology. • The Noy and McGuinness Method: The Noy & McGuinness (2001) guidelines suggest to build an ontology by performing seven main activities: 1 Identification of the domain and scope of the ontology. 2 Reuse of existing ontologies. 3 Enumeration of important terms in the ontology. 4 Definition of classes and class hierarchy. 5 Definition of properties of classes (slots). 6 Definition of facets of the slots. 7 Creation of instances. • The Gruninger and Fox Method (1995) is based on building a logical model that will be specified into an ontology. This is done by: 1 Establishing motivating scenarios that the ontology would serve. 2 Informal competency questions are formulated based on these scenarios that were established. 3 The specification of the terminology of the ontology in a formal language, this is based on the terms extracted from the previous steps. 4 The process then continues but this time with the formal competency questions. 5 From the results of the formal competency questions the specification of axioms and the definition of the terms are formalized. • METHONTOLOGY: A complete ontology development process is proposed by Fernandez et al. (1997). The process is composed by the following phases: specification; conceptualization; formalization; integration; implementation; and maintenance. Its life cycle is based on evolving prototypes and specific techniques pe- culiar to each activity. Other activities, like control, quality assurance, knowledge acquisition, integration, evaluation and documentation are carried out simulta- neously with the ontology development activities. • UPON: UPON (De Nicola & Missikoff 2005) is a methodology based on the Ratio- nal Unified Process. In UPON there are cycles, phases, iterations and workflows. Each cycle consists of four phases (inception, elaboration, construction and transition) and results in the release of a new version of the ontology. 9.1 Assessing the O4IS Design Methodology 279

The Uschold and Gruninger’s skeletal method is a simple development outline, but it does not specify explicitly how an IS designer is to actually carry out the design and development of the ontology. METHONTOLOGY on the other hand, is more familiar to the IS designer, since the phases of the proposed ontology development life cycle is similar to software engineering and development life cycle. Noy and McGuinness have provided an easy to use, simple, tutorial-like guidelines for ontology design and development. Though, their guidelines target the ontology development on Protégé Ontology editor, most of their proposed steps are generic enough to be adopted independent of any tool. UPON, aims to make the best of both worlds by combining Rational Unified Process design process with explicit specification of how the ontology-engineering process should be done. They also elucidate on the roles of a domain knowledge expert and the developer (ontology expert) in the ontology development life cycle.

9.1.2 Requirements Revisited

As stated in section 5.1, we had identiﬁed a set of requirements that our proposed ontology design methodology should meet. In this section we revisit those requirements to assess how far we have fulﬁlled those requirements. We shall compare the functional requirements met by O4IS design methodology with the other surveyed design methodologies in section 9.2.3.

• Easy to follow for IS designers: Our proposed O4IS design methodology follows a template based documentation to provide the guidelines for the entire design process. We also reuse existing software design methodologies as well as known paradigms. This should make the O4IS design methodology easy to follow by an IS designer. • Adaptable for different targeted applications: Our recommendations in the different stages of the O4IS design take into consideration the functional requirements of targeted applications. Our proposed Dual Conceptual Representa- tion and recommendation for level of knowledge representation are examples of such contributions. • Comprehensive to capture the semantics and pragmatics of the domain: We have proposed a methodology for conceptualizing the semantics, procedural and pragmatic aspects of the domain in our proposed USP2 Design. • Explicit domain assumptions: The USP2 Design should aid the IS designer in making domain assumptions explicit. The guidelines for deriving the Semantic Concept View, Procedural Concept View and the Pragmatic Concept View help the designer to analyze and represent the semantic and pragmatic aspects of the domain. The set of Semantic Analysis Representations are also reusable patterns that: aid the designer in the conceptualization; make explicit speciﬁc pragmatics, 280 9 Discussion of Results

dynamic or procedural aspects of social domains; and build on and make use of existing literature and research. • Clear guidelines for the design process: Both the O4IS design methodology and the USP2 Design are presented in simple template-based steps with ample illustrative examples. Furthermore, we have demonstrated the use of the design methodology in two different case studies. • Reusable, shared and understandable domain ontology for both humans and machines: We have proposed a logical architecture for domain ontology (as discussed in section 5.3.1) that makes the domain ontology ﬂexible, and easy to reuse. The Dual Conceptual Representation makes it understandable for both humans and machines. • Objective designing of ontology: We hope to reduce the subjective bias of the IS designer by making the steps in the design process granular. Also, the use of conceptual analysis patterns as put forward by our Semantic Analysis Represen- tations, reduce the differences in conceptualizations.

Though we have targeted the IS designer as our end user for the O4IS design methodology, it is equally applicable and usable by other ontology designers for other domains as well.

9.2 Advantages of O4IS Design Methodology

After reviewing the salient features of O4IS design methodology we now discuss some of the key advantages that O4IS design methodology has to offer.

9.2.1 O4IS Design Methodology useful in all ontology building situations

Existing ontology design methodologies belong to one of the following criteria, depending upon the starting point from where they are built:

• From scratch. • From existing ontologies. • From a corpus of information sources only, without the involvement of subject matter experts. • A combination of the last two approaches.

All ﬁve of our surveyed ontology design methodologies describe in detail the process of building ontologies from scratch. Methontology proposes alternatives to build from existing ontologies or evolving ontologies as they call it. They emphasize on the growth and extension of existing ontologies, but it is unclear how other external ontologies are to be reused in the building of a targeted ontology. Noy and McGuinness propose the reuse of existing ontologies in their ontology-building 9.2 Advantages of O4IS Design Methodology 281 methodology. Our proposed O4IS design methodology can be used in a combination of any of the above mentioned situations. The only exception is that the O4IS design methodology cannot be solely used to build an ontology without any input from domain experts.

9.2.2 O4IS Design methodology proposes Dual Conceptual Representation

Blazquez et al (1998) and Gomez-P´ érez (2001) have observed some of the problems faced by ontology designers: • There is a subjective bias in the ontology, as the visualization of a domain is dependent on the designer. There can never be an absolute model of a given domain. • Conceptual models are implicit in the implementation codes, that is the designers develop the ontology directly in the chosen language of implementation be it OWL, KIF, or any other Logic programs. • The above problem also leads to violation of one of Gruber’s (1993a) design criteria, namely ‘minimum encoding bias’. • Ontology developers find it difficult to understand implemented ontologies of other developers. Our O4IS design methodology solves, or at least reduces, most of the above- mentioned issues. O4IS is the only design methodology (to the best of our knowledge) that actively proposes a Dual Conceptual Representation. We have emphasized on the role of conceptual modeling in the design of ontology. Conceptual models as the intermediary output serve many purposes, like: • Domain assumptions are made explicit in the conceptual models. Nothing is hidden in the implementation code. • Conceptual models are mostly graphical in nature, hence easily understood even by non-information system users, domain experts, and decision makers. They are easily interpreted by other IS designers as well. • Conceptual models are implementation language independent. We can transform the same UML conceptual model into different ontology representation languages. Hence, we reduce the coding bias. Efforts like the ODM aim to facilitate this transformation. Tool support for the same is also under trial. • The conceptual models themselves act as analysis patterns for designers to use in the ontology building.

9.2.3 O4IS Design Methodology considers functional requirements of application purpose

Almost all the ontology design methodologies advocate the design of ontology for a given purpose. Ontologies for Information Systems use definitely need to be de- 282 9 Discussion of Results veloped with the targeted use in mind. At the same time, they need to be reusable across applications. These two requirements are in contrast to each other. Uschold and Gruninger’s skeletal method proposes an informal question list to determine the scope and purpose of the ontology, whereas Gruninger and Fox propose a formal set of competency questions. These are helpful in establishing the content of the ontology being developed. But, for successful use in an information system application, the ontology must also fulfill some other functional requirements, just like any other knowledge or data resource. These functional requirements depend partially on the domain and partially on the intended use, like flexibility, traceability, verifiability as seen in our second case study(section 8.2). Table 9.1 lists some functional requirements and assesses if they are met by O4IS and the other design methodologies. In the table, ‘S’ stands for ‘Supports’, ‘PS’ stands for ‘Partly Supported’, and ‘ND’ stands for ‘Not Described’. The last entry means that we could not judge if the design methodology supported or was not based on the literature that we surveyed. As we can see, O4IS supports all the listed functional requirements. There may be other requirements which may not be addressed, but to the best of our knowledge and in the different domains that we have applied O4IS design methodology, we have found the results to be satisfactory. Table 9.1. Comparison of Ontology Development Methodologies Functional Requirements O4IS Uschold and King Gruninger and Fox METHONTOLOGY Noy and McGuinness UPON Handle unstructured informa- S S/NS ND ND ND S tion as input sources Flexibility and Adaptability S ND ND PS NS S Reuse (Based on) existing S S S S S S knowledge base and information Interoperability S ND ND ND ND S Rapid and easy development S PS PS S S S Formal Representation S S S S S S Informal Representation S S S Maybe NS S Credibility, Authenticity to be S ND ND S ND S verifiable, validated Use as a look up for analysis, S S ND ND ND S at the same time the ontology should grow Legend: S = Supported, NS= Not Supported, ND= Not Described, PS= Partly Supported. 284 9 Discussion of Results

9.3 Evaluating USP2 Design and the Semantic Analysis Representations

We evaluate the USP2 Design and the Semantic Analysis Representations proposed in this research following knowledge representation roles as proposed by Davis et al. (1993) and summarized earlier in section 2.3.2 as:

1 A knowledge representation is a surrogate. A computational model is a substitute for some real- world concept which may be an object or some characteristics of an object or a process that occurs in time. Sowa (2000) explains that a declarative approach is based on constraints or axioms that define the preconditions and post conditions and transformations that may occur for each event in the model. For our chosen knowledge representation both the UML conceptual models and the formal OWL implementations fulfill this criterion. The same conceptual models are used to model the behavior, as well as the underlying semantics. 2 A knowledge representation is a set of ontological commitments. Following Quine’s (1964) criterion and definition of ontology as a study of existence, the characteristics of the concepts or properties or slots as they are known popularly define the ontological commitment of the designer. This criteria overlaps with the design criteria put forward by Gruber (1993a) as well. We follow the OWL modeling recommendations for the OWL translations as well as our conceptual models are based on the theoretical background as discussed in chapter 4. Though a certain amount of subjective bias cannot be avoided, we have tried to adhere to Gruber’s criteria for ontology modeling. 3 A knowledge representation is a fragmentary theory of intelligent reasoning. To support reasoning, the knowledge representation must also describe the behavior and interactions between the ‘things’ that make the model. Our proposed USP2 Design approach fulfills this criterion. We have analyzed and put forward different semantic relationships, namely, structural, prescriptive, temporal, functional and deontic. Our perspective based conceptualization can be used both at design time and later during the use of ontology as well. 4 A knowledge representation is a medium for efficient computation. The model must be computable by machines. As stated earlier, UML conceptual models are translatable to machine- readable OWL. Also, by adopting the ODM recommendations, we have aimed to ensure uniformity and completeness of the UML conceptual models. So, we not only gain the expressiveness and simplicity of graphical UML but also the formal computability of OWL. 5 A knowledge representation is a medium for human expression. A good knowledge representation should facilitate easy communication between knowledge engineers and domain experts who are not AI experts. We believe that this 9.4 Summary of Results 285

principle has been adequately addressed by our design approach as well as the Semantic Analysis Representations.

9.4 Summary of Results

So far, we have assessed the artifacts produced in this research, namely the O4IS design methodology and the other related constructs and methods like the USP2 De- sign, the SARs, etc. We now assess the research methodology that has been adopted to produce the above-mentioned design for Information Systems. To quote Peffers and Tuunanen (2006):

“Information systems (IS) is an “applied” research discipline, we acknowledge, in the sense that we apply theory, frequently from other disciplines, such as economics, computer science, and the social sciences, to solve problems at the intersection of IT and organizations.”

Peffers and Tuunanen summarize the developments in design science in Informa- tion Systems and observe that in the lack of a clear mental model for the practice of research in Information Systems, it is ambiguous to evaluate and ascertain the scien- tiﬁc relevance or contribution that a particular Information Systems research may or may not have. They propose a six-step conceptual process and a mental model called the Design Science Research Process (DSRP) to carry out and produce Information Systems artifacts as discussed earlier in section 1.10. R Peffers et al. (2006) have based their DSRP model on the guidelines proposed by Hevner et al. (2004). Hence, we choose to assess the research methodology followed in this research using the design science guidelines proposed by Hevner et al. (2004) as:

• Design as an Artifact: Must produce a viable artifact, method, model or an instantiation. We have produced a number of artifacts in this research. Firstly we have proposed a design methodology for design and development of ontologies for information systems, called the Ontology for Information Systems (O4IS) design methodology (chapter 5). Secondly, we have produced a number of methods for conceptualization, viz the multi-tier architecture for domain conceptualization, Dual Conceptual Representation for semi-formal and formal conceptualization. Thirdly, we have proposed a number of Semantic Analysis Representations as both models, and constructs for analyzing further domain knowledge. Fourthly, our case studies themselves have given forth valuable and reusable artifacts, that is the Multi-Tiered Contract Ontology and the Defence Conceptual Modeling Framework-Ontology. 286 9 Discussion of Results

• Problem Relevance: Requires creation of a technology-based solution to a real world problem. The problems as we have identified are relevant and contemporary. The need for faster, efficient and accurate information retrieval and processing in Information Systems is well established. Emerging technologies like semantic web and ontologies are supposed to resolve some of the current problems existing in Information Systems. In this research, we have tried to combine existing methodologies and emerging technologies to propose a viable solution for the identified problem. We visualize that our O4IS design methodology is simple and explanatory enough for IS designers to adopt and follow for the design and development of ontologies. • Design Evaluation: The artifact must be useful and hence must be evaluated for its utility, quality and efficacy. The artifacts listed earlier have been theoretically and practically assessed. By using our proposed methodologies in case studies, we have been able to demonstrate its utility. At the same time, feedback and issues faced have led us to refine our proposed design methodology. As stated, this research began with a problem or goal-oriented approach with the first case study. Experiences gained in that case study led us to the second iteration where we refined our design methodology before applying it on our second case study, the DCMF project. The DCMF project had different goals and requirements, hence we had to further adapt our constructs and methods. The proposed artifacts in this thesis are the result of this second iteration. We plan to continuously re- vise and update the proposed solutions if necessary, when we apply the same on more case studies. By adopting standards and recommendations for the knowledge representation, we ensure the quality of the artifacts produced. Some of the artifacts (Deontic Analysis Model) have been evaluated by end users through surveys and empirical tests. • Research Contributions: The artifact must be novel, using a new improved or innovative approach to solve the problem domain. The research contributions must be clear and verifiable. In our survey of related research we have reviewed the current state of the art in ontology design methodologies. In the earlier section 9.2.3, we have presented a comparison of these surveyed ontology design methodologies with O4IS design methodology. The scientific originality and research contribution is thus evident. We have supported active reuse of existing methods, techniques and approaches. Hence, our ten-step guidelines incorporate parts of the state of the art design methodologies as well. Some of the unique and original contributions of the research include: the multi-tiered architecture for domain ontologies; the Dual Conceptual Representation approach; the set of conceptual analysis models for the semantic analysis of relationships including functional, temporal, prescriptive and deontic aspects named SARs that can also be used as constructs; and the main contribution of this thesis is the Unified 9.4 Summary of Results 287

Semantic Procedural Pragmatic design for semantic representation of the semantic and pragmatic aspects of the domain. Note that, we have focused mainly on social domains that are inherently prescriptive or normative in behavior. Our research methods have been documented via this thesis and can be carried out by interested designers and readers. Our conceptual models have been, for the most part, verified by domain experts and based on standardized literature. • Research Rigor: The artifact must be coherent, rigorously defined and internally consistent. Application of rigorous methods in the design and development process must be visible. We have endeavored to be as rigorous and transparent as possible in our design and development process. Our knowledge representation languages chosen, UML and OWL can be verified for consistency by themselves. • Design as a Search Process: The search for an effective artifact requires that available means and methods must have been utilized. As stated earlier, our research has included reuse and incorporation of existing research and methods. Chapters 2, 3 and 4 summarize our study and review of existing and relevant research of interest to us. We have motivated the choices that we have made and shown the reuse of existing methods and research through out our proposed solutions in chapters 5 and 6. • Communication of Research: Design science must be effectively communicated to technology-oriented as well as management-oriented audiences. As listed in chapter 1 (1.14), we have attempted to communicate our results and ideas through a number of publications. Several others are in the pipeline and we hope to continue this knowledge dissemination process. Another form of knowledge dissemination is through teaching other students. This author is actively involved in the supervision of masters’ students in their research as well as some courses where ontology design and development is taught. Some of the students have carried out their research using ideas and solutions proposed in this thesis.

With that we come to the end of our discussion on results achieved. In the ﬁnal chapter we recapitulate our problems, goals and our solution.

O 10

Conclusions

In this final chapter, we recapitulate on our problems, motivations and solutions proposed. We highlight some of the salient points of our research and conclude with a discussion on open issues and work for the future. Peffers and Tuunanen put forward the DSRP conceptual model as a research process, illustrated in figure 1.6. They have identified several possible input starting points for Information Systems research. One of them being the problem-centered approach. Our research began with the identified problems in the realm of business contracts (Case study I). To attain those objectives, we designed and developed the first version of the MTCO. Issues and experience gained in this iteration led us to iterate further and work towards an improved design methodology. The second case study, then, gave us the opportunity to test our improved design methodology. Feedback, evaluation from the end users has led to constant improvements in our design and development. We present the current state of the O4IS design methodology and USP2 Design in this thesis. The DCMF case study is still ongoing and we presume that further iterations and improvements in our proposed artifacts are possible. As we have been following Peffers et al.’s (2006) design science research process (DSRP) model, we use the same one to summarize our work in this research.

10.1 Problem Identiﬁcation and Motivation

To identify the research problem and justify its need for a solution. Problem deﬁnition is to be used to develop an artifact as a solution. Motivation is necessary to convince the readers to understand and accept the results that are proposed. Resources needed for this step is a knowledge of the current state of the art, the relevance of the identiﬁed problem. Chapter 1.3 motivates the need for ontologies to be used in Information Systems like the growing needs of Information Systems, changing facets of business communication and technology and the need for semantic interoperability with global 290 10 Conclusions partners etc. Furthermore, we are interested in social domains where prescriptive norms, pragmatics and social behavior is implicit. Some of the current issues that stop the widespread use of ontologies in Information Systems have been discussed in section 1.4 and a recap is given below:

• Abstract research is not in tandem with applied research and industry. • Ontology design does not cover all of the functional needs of Information Sys- tems. • Ontology design methodologies are not explicit enough and easy to adopt by inexperienced IS Designers. • Ontology design for Information Systems needs to capture and represent prescriptive behavior in addition to descriptive vocabulary.

These issues raise many research questions, the following have been the focus for this research as (section 1.5):

1 How can the semantic and pragmatic aspects of social domains be represented as ontologies that are to be used in Information Systems? 2 How should domain ontologies (of social domains) be designed, considering the functional requirements of Information Systems, including design choices that an IS designer should make with regard to architecture, development strategy, representation language, and selection of tools? 3 For what purposes may an ontology of social domains designed for Information Systems be used?

10.2 Objectives for a solution

To infer the objectives for the proposed solution to the identified problem. The objectives are to be based rationally on the identified problems and should lead to the development of new or improved artifacts. For the problems identified we set up some goals (section 1.6) that outline the objectives for our proposed solution as:

A clear and explanatory design methodology that takes care of functional requirements of Information Systems resolves the issue of ontology design not considering functional requirements. By making explicit the semantics, prescriptive norms and pragmatics of the domain via our USP2 Design takes care of the issue of representing 10.3 Design and Development 291 the semantic and pragmatic aspects of social domains. The O4IS design methodology has been described in a simple template based procedure using strategies and methods prevalent in any Information Systems design and development. Thus, it should be relatively easy for adoption by information system designers. The O4IS design methodology reuses and incorporates existing ontology design methodologies. The second research question is addressed by demonstrating the utility of the proposed design methodology in two different social domains.

10.3 Design and Development

Create the artifacts. Artifacts may be models, methods, constructs, or instantiations. This step includes determining the functionality of the artifact and developing it using a theory. Our contributions made in this thesis are illustrated in ﬁgure 1.7:

• The O4IS design methodology for design of domain ontologies for Information Systems. • The USP2 Design for domain conceptualization of semantics, procedures and pragmatics. The USP2 Design uses and follows Sowa’s discourse on lexical knowledge representation (section 3.3.3). • Set of Semantic Analysis Representations that can be used as constructs for capturing domain knowledge or as reference models for analysis. The Semantic Analysis Representations essentially analyze and conceptualize different types semantic relationships. • The Multi-Tier Domain Ontology architecture for ontology representations that promotes ﬂexibility, extendibility and re-usability. • A Dual Conceptual Representation strategy for a two-step knowledge representation of domain supporting both human and machine users of Information Systems.

Additionally we have a number of ontologies and domain specific artifacts produced in our case studies, namely the Multi tier contract ontology(MTCO), the deontic analysis of contract commitments through Obligation State Analysis. The procedural analysis and alignment to business process models using the Contract Workflow Methodology to deduce Contract Workflow Models(CWM). We have also proposed patterns for CWM analysis using BPMN. In the other case study, we have contributed with a multi-tiered DCMF-O suite. We have adapted existing data model and standard in to ontology. Our case study specific extensions and modifications include the use of ECA rule ontology to capture normative Rule of Engagements. 292 10 Conclusions

The above artifacts have been developed using the proposed theory, viz, O4IS design methodology and USP2 Design.

10.4 Demonstration

Demonstrate the utility of the developed artifact. This may be done via experimentation, simulation, case study, proof or other means. The idea is to demonstrate how the artifact can be used to solve the identiﬁed problem. As discussed in the previous section, our theories have been demonstrated and used in the context of the two case studies mentioned in this thesis. As we discussed in section 7.13, the proposed MTCO has been used in different contexts like for alignment with business process models(section 7.13), to monitor contract performance (section 7.13.2),for exception handling of processes (section 7.13.3), to assess business contract risks (section 7.13.4) and to model the non-functional aspects of enterprises (Kabilan et al. 2007). Similarly the artifacts designed in the context of the second case study, DCMF Project, have been used in proof of concept demonstrations and tools like analysis of case scenarios (section 8.8), Military operation plan visualization and activity diagram visualization. This is an ongoing research and we aim to use the proposed ontologies and methods in different applications including semantic interoperability.

10.5 Evaluation

Observe and measure how well the artifact solves the problem. It includes a comparison of the artifact to the original objectives set up. How far does the artifact fulfill the objectives? Other quantitative assessments may also be done. The proposed O4IS design methodology and its included design approaches, constructs and models as discussed above, meet the objectives set up. A more quantitative or field test of the same is now warranted. We hope that other designers and researchers will test our proposed methodologies and provide us with constructive feedback. As stated, we are following the DSRP model, therefore, this is not the end of a research process but an evolving one. We ourselves plan to apply the O4IS to other domains and applications. A certain degree of subjective bias on the part of this author cannot be ruled out. Hence, it is difficult to estimate exactly how easy an IS designer unfamiliar with ontology modeling, would find the O4IS design methodology. We have tried to be illustrative and simple in our descriptions so that it should be comprehensible to any IS designer. We have also tried to provide the summary of the relevant theoretical background necessary to follow the O4IS design methodology. As stated in section 8.9, we have begun with some field tests of our case study results. We plan to extend our evaluations in the coming years. 10.7 Open Issues and Future Work 293

10.6 Communication

To disseminate knowledge about the problem, its proposed solution and utility to other scientific researchers, practicing professionals via publications in scientific channels, and other disseminating media. We have disseminated our research through publications in scientific conferences and workshops. We have also shared our results in technical documents and at technical workshops like the Simulation Interoperability Workshop, which is a conference for military organizations and defence-related practicing professionals.

10.7 Open Issues and Future Work

To wrap up our discussion, there still remain a few issues that are yet to be resolved like:

• Analysis and representation of business rules and constraints. So far we have proposed to conceptualize them as OCL constraints (section 7.13.3). The current W3C recommendation which will probably become a standard for rule expression is through SWRL (Semantic Web Rule Language). We need a method to translate from OCL to SWRL. The OMG recommendation of the Ontology Def- inition Metamodel(ODM) proposes the use of Common Logic (CL) to capture business constraints. However, it is still unclear how the translation to OWL is to take place. Another OMG proposal, SBVR(Semantic Business Vocabulary and Rule) ontology is something we plan to look at. • Prescriptive Norms and Pragmatics. Our work on the ECA rule ontology is still basic and needs to be improved. It has to be extended to handle all other kinds of conditions and rules. Our Deontic Analysis Model at present only represents the modalities of an obligation. We should extend it to include the entire Language Action Perspective model so that we can analyze all kinds of actions from the intentional aspect. • Ontology Maintenance and Use. We have not addressed any issues regarding the physical storage, retrieval or use of the designed ontology. We have not addressed how or when or by whom an ontology is to be updated and maintained. Research into migration from existing systems to ontologies is also warranted. Interoperability of actual Information Systems using ontologies is to be tested. Methods, approaches and tools for accomplishing the above are also possible research topics for the future. 294 10 Conclusions

10.8 Conclusion

Man has been on the quest for truth and knowledge from time immemorial. Some believe in absolute truth, but this research has followed the existence of a relative and pragmatic truth as is supported by Information Systems(see our discussion in section 3.3.4). Just as Barry Smith (2003a, 2004) has pointed out, philosophers can learn from the experiences of problem-solving ontology engineers and vice versa. Smith however criticizes the relativist concept of possible worlds. We believe that the knowledge engineers (both within AI and Information Systems) came up with the idea of possible worlds because their ‘experiments’ and ‘observations’ showed them that it is not possible to be completely free of ontological commitment and bias as recommended by the philosophers. The same conceptualization of the same domain could be represented differently, interpreted differently, analyzed differently, depending on who is doing the same, or in which context or under what circumstances. Therefore, the utility of a conceptualization becomes shareable and reusable only when the context and specifics of the ontological commitment are made obvious and thus, the delimitation of conceptualization of possible worlds. It implies that the proposed theorems and truth statements are valid within the boundaries described. Such an approach is well within the realm of a relativist philosopher who believes in the existence of relative truth and not the absolute truth. Even the pure philosophical ontologist would have to agree that in their complete world as is, it still would not be possible to capture all aspects, and flavors of a concept. And different philosophers have different views of the world, thereby indulging in ontological bias. If establishing consensus regarding the conceptual models would free an ontology of its ontological bias, then the same approach can be easily applied to the knowledge engineering perspective as well. Our work and results have shown that Haack’s version of possible worlds (section 3.3.1 is valid. Our conceptual design approach has been to declaratively capture one possible vision of a possible world. In that respect, we have tried to combine the linguistic and AI approach for ontology modeling. From Linguistics, we have reviewed the works of (Nirenburg & Raskin 2001) where they have laid the foundation for what should be described in the semantics of an ontology (section 3.3.2). As we can now see, our proposed conceptual models, the design rationale behind the USP2 Design has been laid on the theoretical background laid by Nirenburg and Raskin. Our knowledge representations also conform to the roles that (Davis et al. 1993) (see section 2.3.2) propose– that of a medium of human expression and a surrogate model for the real world. We started off on this research journey with the objectives of promoting the use of ontologies in Information Systems. To do that, ontology design had to be made simple and illustrative enough for information system designers to follow. Given 10.8 Conclusion 295 the complex philosophy that drives ontology, we needed to put forward conceptual models as stepping stones for designers to understand and use as constructs (building blocks of Nirenburg and Raskin, as also supported by Sowa). We may not have reached our final destination, but we feel that we have made sufficient progress towards that goal – an incremental increase in the re-usable knowledge resource of mankind (limited to Information Systems context).

References

Aalst, W. M. P. v. d. (1994), ‘Modelling and analysing workflow using a petri-net based approach’, Proceedings of the second Workshop on Computer-Supported Cooperative Work, Petri nets and related formalisms pp. 31–50. Aalst, W. M. P. v. d. (1998), ‘The application of petrinets to workflow management’, The Journal of Circuits, Systems and Computers 8(1), 21–66. Aalst, W. M. P. v. d. (1999), ‘Formalization and verification of event-driven process chains’, Information and Software Technology 41(10), 639–650. Ackoff, R. (1989), ‘From Data to Wisdom’, Journal of Applied Systems Analysis 16, 3–9. Albert, S. (1998), ‘Knowledge management tries to live up to the hype’, MidRange Systems . Alexander, C., Ishikawa, S. & Silverstein, M. (1977), A Pattern Language: Towns, Buildings, Construction, Oxford University Press. Angelov, S. G. (2001), B2b econtract handling - a survey of projects, papers and standards ctit technical report, Technical report, University of Twente. Artale, A., Franconi, E., Guarino, N. & Pazzi, L. (1996), ‘Part-whole relations in object-centered systems: An overview’, Data Knowledge Engineering 20(3), 347–383. Austin, J. L. (1962), How to do things with words, Oxford: Oxford University Press. Avison, D. & Fitzgerald, G. (1995), Information Systems Development: Methodologies, Techniques and Tools, 2 edn, McGraw Hill, Maidenhead. Baclawski, K., Kokar, M., Kogut, P., Hart, L., Smith, J., Holmes, W., Letkowski, J. & Aronson, M. (2001), ‘Extending UML to support ontology engineering for the semantic web’, UML pp. 342–360. Bergamaschi, S., Castano, S., di Vimercati, S., Montanari, S. & Vincini, M. (1998), ‘An intelligent approach to information integration’, Proceedings of International Conference on Formal Ontology in Information Systems (FOIS’98), Trento, Italy . Berners-Lee, T., Hendler, J. & Lassila, O. (2001), ‘The semantic web’, Scientific American 284(5), 34–43. Bittner, T., Donnelly, M. & Smith, B. (2004), ‘Endurants and perdurants in directly depicting ontologies’, AI Communications 13(4), 247–258. Blazquez, M., Fernandez, M., Garcia-Pinar, J. & Gomez-P´ érez, A. (1998), ‘Building ontologies at the knowledge level using the ontology design environment’, Proceedings of the KAW98 . 298 References

Boman, M., Johannesson, P., Janis, B. A. & Wangler, B. (1997), Conceptual Modelling, Prentice Hall. books, I. (2002), ICC International contract for sale of perishable goods, ICC books. Borgida, A. (1995), ‘Description logics in data management’, IEEE transactions on knowledge and data engineering 7(1). Borgida, A. & Brachman, R. J. (2000), Description Logic Handbook, Cambridge University Press, chapter Conceptual Modelling with Description Logics, pp. 359–381. Borst, P., H., A. & Top, J. (1997), ‘Engineering ontologies’, International Journal of Human-Computer Studies 46 (Special Issue on Using Explicit Ontologies in KBS Development) pp. 365–406. Brachman, R. J. (1977), ‘What’s in a concept: Structural foundations for semantic networks’, International Journal of Man-Machine Studies 9(2), 127–152. Bradley, F. H. (1914), Essays in truth and reality, Oxford Press. Bubenko, J. A. (2007), Conceptual Modelling in Information Systems Engineering, Springer-Verlag Berlin Heidelberg, chapter From Informational Algebra to Enterprise Modelling and Ontologies– a Historical Perspective on Modelling for Information Systems, pp. 1–18. Bucciarelli, M. & Johnson-Laird N, P. (2005), ‘Naive deontics: A theory of meaning, representation, and reasoning’, Cognitive Psychology 50 (2005) pp. 159–193. Cabot, J. & Raventos, R. (2004), ‘Roles as entity types: A conceptual modeling pattern’, International conference on conceptual modeling (ER 2004) pp. 69–82. Carey, S., Kleiner, M., Hieb, M. & Brown, R. (2001), ‘Standardizing battle management language a vital move towards the army transformation’. Chen, P. P. (1976), ‘The entity-relationship model -toward a uniﬁed view of data.’, ACM Translations of Database Systems. 1(1), 9–36. Chen, P. P. (1983), ‘ER - A historical perspective and future directions’, Proceedings of the 3rd Int. Conf. on Entity-Relationship Approach (ER’83) pp. 71–77. Chen, P. P., Thalheim, B. & Wong, L. Y. (1999), ‘Future directions of conceptual modeling’, Conceptual Modeling: Current Issues and Future Directions 1565, 294–308. Chen, Y. (2006), Contract execution monitoring and conformance testing of business contracts, Master’s thesis, Department of Computer and Systems Sciences, Royal Institute of Technology and Stockholm University. Chira, O. (2003), Ontologies, Technical report, IDIMS (The Intelligent Agent Based Collaborative Design Information Management and Support Tools (IDIMS) project) Report. Clarke, R. (1995), ‘Information systems: The scope of the domain.’, http://www.anu.edu.au/people/Roger.Clarke/SOS/ISDefn.html. Last accessed on 2007-07-20. Colomb, M. R. (2002), Extending ontology to behaviour in communities of interoperating information systems agents, Technical report, ISIB-CNR. Community Research and Development Information Service: Glossary (Web Resource), http://www.cordis.lu/ist/ka1/administrations/publications/glossary.htm. Last accessed on 2007-07-20. References 299

Consortium, W. W. W. (Web Resource), ‘Wordnet in RDFS and OWL’, http://www.w3.org/2001/sw/BestPractices/WNET/wordnet-sw-20040713.html. Last accessed 2006-05-30. Corcho, O., Fernandez, M., Gomez-P´ érez, A. & Lopez-Cima,´ A. (2005), ‘Building legal ontologies with METHONTOLOGY and WebODE’, 3369, 42–157. Cranefield, S. (2001), ‘UML as an ontology modelling language’. Cranefield, S. & Purvis, M. (1999), ‘UML as an ontology modelling language’. Cristani, M. & Cuel, R. (2007), A survey on ontology creation methodologies, in A. Sheth & M. Lytras, eds, ‘Semantic Web-based Information Systems– state of the art applications.’, CyberTech Publishing. Dale, J. (2002), Ontology, Montreal and Kingston: McGill-Queen University Press. Daskalopulu, A. (2002), ‘Evidence based electronic contract performance monitoring’, The INFORMS Journal of Group Decision and Negotiation. Special Issue on Formal Modelling in E-Commerce . Daskalopulu, A. & Maibaum, T. S. E. (2001), ‘Towards electronic contract performance’, p. 771. Daskalopulu, A. & Sergot, M. J. (1997), ‘The representation of legal contracts’, AI and Society 11, 6–17. Davis, R., Shrobe, H. & Szolovits, P. (1993), ‘What is a knowledge representation?’, AI Magazine 14(1), 17–33. De Nicola, A. & Missikoff, M. (2005), ‘A proposal for a unified process for ontology building: UPON’, Lecture Notes in Computer Science, Volume 3588,Pages 655 – 664 . Dignum, F., Weigand, H., Kruezen, W., Kemme, T. & van de Riet, R. (1987), ‘Constraint modelling using conceptual prototyping language’, Data and Knowledge Engineering pp. 213–254. Dik, S. (1978), Functional Grammar, North-Holland, Amsterdam. Ding, L., Finn, T., Joshi, A., Peng, Y., Scott Cost, R., Sachs, J., Reddivari, P. & Doshi, V. (2004), ‘Swoogle: A semantic search and metadata engine’, ACM Thirteenth Conference on Information and Knowledge Management (CIKM04) . Last accessed on 2007-07-20. Doyle, J. & Patil, R. (1989), ‘Two dogmas of knowledge representation’, MIT LCS Technical Memo 387B . A revised version of this paper appeared as Doyle J., and Patil R, Two theses of knowledge representation: Language restrictions, taxonomic classification, and the utility of representation services, Artificial Intelligence, 48(3):261-297, 1991. EC Directives 1998 (n.d.), http://europa.eu.int/comm/enterprise/newapproach/standardization/harmstds/reflist.html. Last accessed 2003-11-12. Fensel, D., van Harmelen, M., Klein, M. & Akkermans, H. (2000), ‘On-To-Knowledge: Ontology based tools for knowledge management’, Proceedings of E-Business and E-Work . Fernandez, E. B. & Yuan, X. (2000), ‘Semantic analysis patterns’, Proceedings of the 19th International Conference on Conceptual Modeling (ER 00), LNCS 1920 pp. 183–195. Fernandez, M., Asuncion Gomez-P´ érez, A. & Juristo, N. (1997), ‘METHONTOLOGY: from ontological art towards ontological engineering’, Proceedings of the AAAI97 Spring Symposium Series on Ontological Engineering pp. 33–40. 300 References

Fernandez, M., Gomez-P´ érez, A., Sierra, A. & Pazos, J. S. (1999), ‘Building a chemical ontology using METHONTOLOGY and the ontology design environment.’, IEEE Expert (Intelligent Systems and Their Applications) 14(1), 37–46. Fikes, R. & Farquhar, A. (1999), ‘Distributed repositories of highly expressive reusable ontologies’, IEEE Intelligent Systems pp. 73–79. Fintel, K. v. (2006), Modality and language, in B. Donald M, ed., ‘Encyclopedia of Philosophy’, 2 edn, Macmillan Reference USA. Fonseca, F. (2006), ‘The double role of ontologies in information science research’, Journal of the American Society for Information Science and Technology 58(6), 786–793. Fowler, M. (1997), Analysis Patterns: Reusable Object Models, Addison-Wesley. Fox, M. S. (1992), ‘The TOVE project: A common-sense model of the enterprise’, Industrial and Engineering Applications of Artificial Intelligence and Expert Systems pp. 25–34. Galliers, R. (1987), Information analysis: selected readings, Addison Wesley, Wokingham. Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1994), Design Patterns: Elements of Reusable Object Oriented Software, Addison-Wesley. Gangemi, A., Pisanelli, D. & Steve, G. (2001), ‘A formal ontological framework to represent norm dynamics’. Geerts, G. & McCarthy, W. E. (2000), ‘The ontological foundation of REA Enterprise Ontology’, http://www.msu.edu/user/mccarth4/rea-ontology/. Geyer-Schulz, A. & Hahsler, M. (2002), ‘Software reuse with analysis patterns’, Proceedings of AMCIS 2002 . Glossary of Terms, Management Information Systems (Web Resource), www.321site.com/greg/courses/mis1/glossary.htm. Last accessed on 2007-07-20. Gomez-P´ érez, A. (2001), ‘A proposal of infrastructural needs on the framework of the semantic web for ontology construction and use’, Proceedings of the FP6 Programme Consultation Meeting 9 . Gomez-P´ érez, A., Fernandez, M. & de Vincente, A. (1996), ‘Towards a method to conceptualize domain ontologies.’, Working notes of the workshop Ontological Engineering. ECAI 96 pp. 41–52. Gomez-P´ érez, A., Juristo, N. & Pazos, J. (1995), Towards Very Large Knowledge Bases - Knowledge Building and Knowledge Sharing, Amsterdam, IOS Press, chapter Evaluation and assessment of knowledge sharing technology, pp. 289–296. Goodchild, A., Herring, C. & Milosevic, Z. (2000), ‘Business contracts for B2B’. GOOGLE search engine (Web Resource), http://www.google.com. Last accessed on 2007-07-20. Griffel, M., Boger, H., Weinreich, W. & Lamersdorf, M. M. (1998), ‘Electronic contracting with COSMOS - how to establish, negotiate and execute electronic contracts on the internet’. Grosof, B. N. & Poon, T. (2003), ‘Sweetdeal: Representing agent contracts with exceptions using xml rules, ontologies and process descriptions’, WWW pp. 340–349. Grosof, B. N., Yannis, L. & Chan, H. Y. (1999), ‘A declarative approach to business rules in contracts: Courteous logic programs in xml’. Group, O. M. (2006), ‘Ontology definition metamodel proposal’. August 2005. Accessed 2006-11-10. References 301

Gruber, T. R. (1993a), Toward principles for the design of ontologies used for knowledge sharing, in ‘Presented at the Padua workshop on Formal Ontology, March 1993’. Gruber, T. R. (1993b), ‘A translation approach to portable ontology specification’, Knowledge Aquisition 5(2), 199–220. Gruninger, M. & Fox, M. (1994), ‘The role of competency questions in enterprise engineering’. Gruninger, M. & Fox, M. (1995), ‘Methodology for the design and evaluation of ontologies’, Proceedings of Int. Joint Conf. AI 1995, Workshop on Basic Ontological Issues in Knowledge Sharing . Guarino, N. (1998), ‘Formal ontology and information systems.’, Proceedings of Formal Ontology and Information Systems(FOIS 1998) pp. 3–15. Guarino, N., Borgo, S. & Masolo, C. (1997), ‘Logical modelling of product knowledge: Towards a well-founded semantics for step.sophia antipolis, france.’. Guarino, N. & Giaretta, P. (1995), ‘Ontologies and knowledge bases: Towards a terminological clarification’, Towards Very Large Knowledge Bases: Knowledge Building and Knowledge Sharing pp. 25–32. Gupta, U. G. (2000), Information Systems. Sucsess in the 21st century, Prentice-Hall, New Jersey. Haack, S. (1978), Philosophy of Logic, Cambridge University Press. HAKIA: The search for meaning (Web Resource), http://www.hakia.com/. Last accessed on 2007-07-20. Halpin, T. (1998), Handbook of Architectures of Information Systems., Springer-Verlag, Berlin, chapter Object Role Modelling (ORM/NIAM). Hayes, P. (1985), Readings in Knowledge Representation, Morgan Kaufmann Pub, chapter The Logic of Frames, pp. 288–295. Hendler, J. & Lassila, O. (2001), ‘The semantic web’, Scientific American 284(5). Heuvel, W. v. d. & Weigand, H. (2000), Cross organizational workflow integration using contracts, in ‘Proceedings of Business Object Component workshop held in conjunction with (OOPSLA 2000)’. Hevner, A. R., March, S. T., Park, J. & Ram, S. (2004), ‘Design science in information systems research’, MIS Quarterly 28(1), 75–106. Hintikka, J. (1962), Knowledge and Belief, Cornell University Press. Hoede, C. & Willems, M. (1989), Knowledge Graphs and Natural Language, Memorandum no.811, University of Twente, Enschede, The Netherlands. Husserl, E. (1970), Logical Investigations, London: Routledge and Kegan Paul. Information Assurance Terminology,IASO certification course,School of Information Technology. (Web Resource), http://ia.gordon.army.mil/iaso/keyterms.htm. Last accessed on 2007-07-20. Information Systems. (Web Resource), http://en.wikipedia.org/wiki/Information_system. Last accessed on 2007-07-20. Jarrar, M. & Meersman, R. (2002), ‘Formal ontology engineering in the DOGMA approach’, 1st International Conference on Ontologies, Databases and Application of Semantics (ODBASE’02), Lecture Notes in Computer Science 2519, 1238–1254. 302 References

Johannesson, P. & Wohed, P. (1998), ‘Deontic specification patterns - generalisation and classification’, Formal Ontology in Information Systems . Jones, A. & Sergot, M. (1992a), ‘Deontic logic in the representation of law: Towards a methodology.’, Artificial Interlligence and Law 1(1), 45–64. Jones, A. & Sergot, M. (1992b), ‘On the charecterisation of law and computer systems: The normative systems perspective.’, In Deontic Logic in Computer Science: Normative System Specification. . Kabilan, V. (2003), ‘Using multi-tier contract ontology to model contract workflow models’, Licentiate Thesis- Royal Institute of Technology . Kabilan, V. (2005), Contract workflow model patterns using BPMN, in ‘Proceedings of 10th International Workshop on Exploring Modelling Methods in System Analysis and Design, collocated with CAiSE 2005’. Kabilan, V., De Nicola, A., Missikoff, M. & Mojtahed, V. (2006), ‘Practical issues in ontology modelling: The case of the defence conceptual modelling framework-ontology.’, Proceedings of Interoperability for Enterprise Software and Applications Conference I-ESA2006 . Kabilan, V. & Johannesson, P. (2003), ‘Semantic representation of contract knowledge using multi-tier contract ontology’, Proceedings of Semantic Web and Databases Workshop (SWDB 2003) . Kabilan, V. & Johannesson, P. (2004), ‘UML for ontology modelling and interoperability’, Proceedings of 1st INTEROP-EMOI Open Workshop on Enterprise Models and Ontologies for Interoperability, Co Located with CAiSE 2004 . Kabilan, V., Johannesson, P. & Rugaimukammu, D. (2003), ‘Business contract obligation monitoring through use of multi-tier contract ontology’, Proceedings of Workshop on Regulatory Ontologies (Worm CoRe 2003) . Kabilan, V., Johannesson, P., Ruohomaa, S., Moen, P., Herrmann, A., Ahlfeldt, R. & Weigand, H. (2007), ‘Introducing the common non-functional ontology.’, Proceedings of Interoperability for Enterprise Software and Applications Conference I-ESA2007 . Kabilan, V. & Mojtahed, V. (2006a), ‘DCMF-O adapting JC3IEDM as ontology an experience report’, Proceedings of FALL SIW 06, FALL Simulation Workshop, Orlando, Florida . Kabilan, V. & Mojtahed, V. (2006b), ‘Introducing the DCMF-O:ontology suite for defence conceptual modelling framework’, EUROSIW 2006 . Kabilan, V. & Svan, P. (2007), ‘ECA rule ontology: Modeling prescriptive rules as descriptive ontology’, Proceedings of 3rd International Conference on Web Information Systems and Technologies, WEBIST2007 . Kabilan, V. & Weigand, H. (2006), ‘Risk assessment of business contracts.’, 1st International Workshop on Interoperability Solutions to Trust, Security, Policies and QoS for Enhanced Enterprise Systems (IS-TSPQ ) 2006, collocated with INTEROP-ESA 2006. . Kabilan, V., Zdravkovic, J. & Johannesson, P. (2005), ‘Use of multi-tier contract ontology to deduce contract workflow models for enterprise interoperability’, Proceedings of 2nd INTEROP-EMOI open workshop on Enterprise Models and Interoperability collocated with CAISE 2005 . Kangassalo, H. (1983), ‘Concept D - a graphical formalism for representing concept structures’, Second Scandinavian Research Seminar on Information Modeling and Database Management 19. References 303

Kant, I. (1800), Logic, Dover Publications. ISBN-0-486-25650-2. Karlapalem, K., Dani, A. R. & Radha, K. (2001), A frame work for modelling electronic contracts, in ‘Proceedings of Entity Relationship and Conceptual Modelling ER 2001, LNCS 2224’, pp. 193–207. Karteseva, V., Tan, Y.-H. & Gordijn, J. (2004), ‘Developing a modelling tool for designing control mechanisms in network organisations’, Proceedings of the 17th Bled International e-Commerce Conference. . Kashyap, V. & Sheth, A. (1998), Semantic heterogeneity in global information systems: The role of metadata, context and ontologies, in M. P. Papazoglou & G. Schlageter, eds, ‘Cooperative Information Systems’, Academic Press, San Diego, pp. 139–178. Kauppi, R. (1967), Einfhrung in die Theorie der Begriffssysteme, Acta Universitatis Tamperensis, Ser. A, Vol. 15, Tampereen yliopisto, Tampere. Kecheng, L. (2000), Semiotics in Information Systems Engineering, Cambridge University Press. Kent, R. E. (2001), ‘The IFF Foundation Ontology’, IJCAI 2001 Ontology Workshop . Key Terminology, Computer and Information Technology (Web Resource), http: //www.tech.purdue.edu/southbend/academics/degreeprograms/cit/cit_term.cfm. Last accessed on 2007-07-20. Kripke, S. (1959), ‘A completeness theorem in modal logic’, Journal of Symbolic Logic 24(1), 1–14. Kripke, S. (1976), In Truth and Meaning, Oxford University Press, chapter Is there a problem with substitutional quantiﬁcation. Kuhn, T. (1996), The Structure of Scientiﬁc Revolutions, 3 edn, University of Chicago Press. Lee, R. M. (1988), ‘A logic model for electronic contracting’, Decision Support Systems 4, 27–44. Lee, R. M. (1998), ‘Towards open electronic contracting’, Electronic Markets 8(3). Lewis, D. K. (1973), Counterfactuals, Blackwell Publishing Limited. Lombardi, V. (2003), ‘Noise between stations: A metadata glossary.’, http://www.noisebetweenstations.com/personal/essays/metadata_glossary/ metadata_glossary.html. Last accessed on 2007-07-20. Maglitta, J. (1996), ‘Know-How, Inc’, Computerworld 30(1). Malhotra, Y. (2001), ‘Expert systems for knowledge management:crossing the chasm between information processing and sense making’, Expert Systems with Applications pp. 7–16. McGuinness, D. L. (2000), Conceptual modelling for distributed ontology environments, in ‘Proceedings of the Eight International Conferences on Conceptual Structures Logical, Linguistic, and Computational Issues (ICCS 2000)’. Mealy, G. H. (1967), ‘Another look at Data’, Proceedings of the Fall Joint Computer Conference (AFIPS) 31, 525–534. Milosevic, Z. & Dromey, R. G. (2002), ‘On expressing and monitoring behaviour in contracts’, Proceedings of 6th International Enterprise Distributed Object Computing Conference (EDOC) 2002 . Milosevic, Z., Josang, A., Patton, M. A. & Dimitrakos, T. (2002), Discretionary enforcement of electronic contracts, in ‘Proceedings of 6th International Enterprise Distributed Object Computing Conference (EDOC) 2002’. 304 References

Milton, N. (2003), ‘Knowledge management.’, http://www.epistemics.co.uk/Notes/40-0-0.htm. Last accessed on 2007-07-20. MITRE (April 2006), Electronic health records overview, Technical report, Center for Enterprise Modernization. McClean, Virginia. Mojtahed, V., Garcia, M., Kabilan, V., Andersson, B. & Svan, P. (2005), DCMF - Defence Conceptual Modelling Framework, Technical report, Swedish Defence Research Agency, FOI, FOI-R–1754-SE. Mylopoulos, J. (1985), On Knowledge Base Management Systems: Integrating Artificial Intelligence and Database Technologies, Springer, Topics in Information Systems, chapter On Knowledge Base Management Systems, pp. 3–8. Naeve, A. (2007), The human semantic web: Shifting from knowledge push to knowledge pull, in A. Sheth & M. Lytras, eds, ‘Semantic Web-based Information Systems– state of the art applications.’, CyberTech Publishing. Nations, U. (1980), ‘United nations convention on contracts for the international sale of goods’, http://www.jus.uio.no/lm/un.contracts.international.sale.of.goods. convention.1980/doc.html. Last accessed on 2007-07-21. Niinimaki, M. (2004), Conceptual Modelling Languages, PhD thesis, Department of Computer Sciences, University of Tampere, Finland. Nijssen, G. M. & Halpin, T. (1989), Conceptual Schema and Relational Database Design, Prentice Hall, Upper Saddle River, New Jersey. Niles & Pease, A. (2001), Towards a standard upper ontology., in C. Welty & B. Smith, eds, ‘Proceedings of the 2nd International Conference on Formal Ontology in Information Systems (FOIS-2001)’. Ninan, D. (2005), ‘Two puzzles about deontic necessity’, http://web.mit.edu/dninan/www/deontic.pdf (last accessed on 31st May 2006). Nirenburg, S. & Raskin, V. (2001), ‘Ontological semantics, formal ontology and ambiguity’, Proceedings of FOIS . Nirenburg, S. & Raskin, V. (2004), Ontological Semantics, MIT Press, Cambridge. Noy, N. & Hafner, C. D. (Fall 1997), ‘The state of the art in ontology design: A survey and comparative review’, AI Magazine 18(3), 53–74. Noy, N. & McGuinness, D. (2001), Ontology development 101: A guide to creating your first ontology, Technical report, Stanford University. OASIS (2002), Collaboration protocal profile and agreement specification 2.0, Technical report, OASIS ebXML Collaboration Protocol Profile Agreement Technical Committee. O’Brien, J. A. (2002), Management Information Systems- Managing Information Technology in the E-Business Enterprise, McGraw Hill Irwin. Olive, A. (2004), ‘Definition of events and thier effects in object-oriented conceptual modeling languages’, LNCS 3288, 136–149. OMG & Group, B. R. (2006), Semantics of business vocabulary and business rules, Technical report, Object Management Group. Available at http://www.omg.org/docs/dtc/06-08-05.pdf. Opdahl, A. L. & Henderson-Sellers, B. (2005), ‘A Unified Modeling Language without referential redundancy’, Data and Knowledge Engineering, Special issue on Quality in Conceptual Modeling. 55(3), 277–300. References 305

Opdahl, A. L., Henderson-Sellers, B. & Barbier, F. (2001), ‘Ontological analysis of whole-part relationships in OO-models.’, Information and Software Technology 43(6), 387–399. Palmer, F. R. (1990), Modality and the English Modals, 2nd edition edn, London/New York: Longman. First Printed in 1979, reprinted in 1990. Papamarkos, G., Poulovassilis, A. & Wood, P. (2003), ‘Event condition action rule languages for the semantic web’, In proceedings of International Workshop on Semantic Web and Databases . Peffers, K., Tuunanen, T., Gengler, C., Rossi, M., Hui, W., Virtanen, V. & Bragge, J. (2006), The design science research process: A model for producing and presenting information systems research., in ‘Proceedings of First International Conference on Design Science Research in Information Systems and Technology- DESRIST2006’. Persson, J. (2007), Visualization and reuse of a Generic Process Ontology, Master’s thesis, Department of Computer and Systems Sciences, Royal Institute of Technology and Stockholm University. Petri, C. A. (1962), Kommunikation mit Automaten., Ph. D. Thesis. University of Bonn. Pierce, C. S. (1933), Collected Papers of Charles Peirce– Vol. IV, The Simplest Mathematics, Harvard University Press. Poli, R. (2003), ‘Descriptive, formal and formalized ontologies, university of trento’, Husserl’s Logical Investigations Reconsidered- Dordrect pp. 183–210. Power, D. (1995), ‘Decision support systems glossary.’, http://dssresources.com/glossary/dssglossary1999.html. Last accessed on 2007-07-20. Quine, W. (1964), ‘Ontological reduction and the world of numbers’, The Ways of Paradox . Ramberg, J. (1999), ICC Guide to Incoterms 2000, ICC Publications. Rescher, N. (1973), The Coherence Theory of Truth, Oxford University Press. Russell, B. (1956), ‘The philosophy of logical atomism’, Logic and Knowledge. ed. Marsh (Allen and Unwin) . Schank, R. C. (1975), Conceptual Information Processing, North-Holland,Amsterdam and American Elsevier, New York. Schon, D. (1993), The Reﬂective Practitioner: How Professionals Think in Action, Basic Books, New York. Searle, J. (1969), Speech acts: An essay in the philosophy of language., Cambridge: Cambridge University Press. Sergot, M. J. (1990), ‘The representation of law in computer programs: A survey and comparison.’, Knowledge Based Systems and Legal Applications. . Smith, B. (2003a), Blackwell Guide to the Philosophy of Computing and Information, Oxford-Blackwell, chapter Ontology and Information Systems -A longer draft version of Ontology, pp. 155–166. Full Draft available at www.ontology.buffalo.edu/ontology(PIC).pdf last accessed on 8th April 2006. Smith, B. (2004), ‘Beyond concepts: Ontology as reality representation’, Proceedings of FOIS 2004, International Conference on Formal Ontology and Information Systems . Smith, H. (2003b), ‘The role of ontological engineering in B2B net markets, director of strategy, e business’, www.ontology.org. Accessed on 2003-06-04. 306 References

Sowa, J. F. (1976), ‘Conceptual graphs for a data base interface’, IBM Systems Research Institute . Sowa, J. F. (1984), Conceptual Structures: Information Processing in Mind and Machine, Addison-Wesley, Reading, MA. Sowa, J. F. (1999), Knowledge Representation: Logical, Philosophical, and Computational Foundations, Course Technology. Sowa, J. F. (2000), Knowledge representation: logical, philosophical and computational foundations, Brooks/Cole Publishing Co. Stevens, W., Myers, G. & L., C. (1974), ‘Structured design’, IBM Systems Journal 13(2), 115–139. Storey, V. C. & Purao, S. (2004), ‘Understanding relationships: Classifying verb phrase semantics.’, LNCS 3288, 336–347. Studer, R., Benjamins, R. & Fensel, D. (1998), ‘Knowledge engineering: Principles and methods’, Data and Knowledge Engineering pp. 161–197. Sukkarieh, J. (2001), Natural Language for Knowledge Representation, PhD thesis, University of Cambridge. Tan, Y. H. (1998), ‘Modeling directed obligations and permission in trade contracts’, 31st Annual Hawaii International Conference on System Sciences 5. Tan, Y. H. & Thoen, W. (2000), ‘A logical model of directed obligations and permissions to support electronic contracting’, The International Journal of Electronic Markets 10(1). Tan, Y. H. & Thoen, W. (2002), ‘Using event semantics for modeling contracts’, Proceedings of 35th Hawaii International Conference on System Sciences - 2002 . Tarski, A. (1944), ‘The semantic conception of truth (1944)’, Philosophy and phenomenological Research 4 . Tarski, A. (1956), ‘The concept of truth in formalised languages (1931)’, Logic, semantics, and mathematics p. Oxford University Press. Translated by Woodger, J H. Tempich, C., Pinto, S., Staab, S. & Sure, Y. (2004), ‘A case study in supporting distributed, loosely-controlled and evolving engineering of ontologies (diligent)’. Turban, E. (1993), ‘Knowledge acquisition review’, Expert Systems and Applied Artiﬁcial Intelligence pp. 117–139. Turnitsa, C., Kovvuri, S., Tolk, A., DeMasi, L., Dobbs, V. & Sudnikovich, B. (2004), ‘Lessons learned from C2IEDM mappings with XBML’. UNIDROIT principles of International Commercial Contract, 1994 (1994), http://www.unidroit.org/english/principles/pr-main.htm. Accessed 2003-06-12. United Nations Commission on International Trade And Law (n.d.), http://www.uncitral.org/. Accessed 2003-06-12. United Nations Standard Products and Service Codes (Web Resource), http://www.unspsc.org. Uschold, M. (1998), ‘Knowledge level modelling: concepts and terminology’, The Knowledge Engineering Review pp. 5–29. Uschold, M. & Gruninger, M. (1996), ‘Ontologies principles, methods and applications’, The Knowledge Engineering Re-view 11(2): 93–136 . Uschold, M. & King, M. (1995), ‘Towards a methodology for building ontologies’, Workshop on Basic Ontological Issues in Knowledge Sharing (IJCAI-95) . References 307

Uschold, M., King, M., Moralee, S. & Zorgios, Y. (1995), The Enterprise Ontology, Technical report, Artificial Intelligence Applications Institute at the University of Edinburgh. van der Aalst, W. M. P., ter Hofstede, A. H. M., Kiepuszewski, B. & Barros, A. P. (2000a), ‘Advanced workflow patterns’, 7th International Conference on Cooperative Information Systems (CoopIS 2000) 1901, 18–29. van der Aalst, W. M. P., ter Hofstede, A. H. M., Kiepuszewski, B. & Barros, A. P. (2000b), Workflow patterns, Technical report, BETA Working Paper Series, WP 47, Eindhoven University of Technology, Eindhoven,. Vanderveken, D. & MacQueen, K. (1990), Semantic Analysis of English Performative Verbs, Cambridge University Press, chapter Chapter 6 of The Principles of Language Use (Volume II) of Meanings in Speech Acts. Wache, H., Vgele, T., Visser, U., Stuckenschmidt, H., Schuster, G., Neumann, H. & Hubner, S. (2001), ‘Ontology-based integration of information - a survey of existing approaches’, Proceedings of the IJCAI-01 Workshop: Ontologies and Information Sharing . Wand, Y., Storey, V. C. & Weber, R. (1999), ‘An ontological analysis of the relationship construct in conceptual modeling’, ACM Transactions of Database Systems. 24(4), 494–528. Wand, Y. & Weber, R. (1990), ‘MARIO BUNGEs ontology as a formal foundation for information systems concepts’, Studies on MARIO BUNGEs Treatise pp. 123–149. Wand, Y. & Weber, R. (2002), ‘Research commentary:information systems and conceptual modelling’, Information Systems Research 13, 363–376. Wand, Y. & Weber, R. (2004), ‘Reflection:ontology in information systems.’, Journal of Database Management 15(2), iii–vi. Weiringa, R. & Meyer, J. (1993), Deontic Logic in computer Science: Normative Systems, John Wiley and Sons Ltd. Chichester, UK., chapter Applications of Deontic Logic in Computer Science:A concise Overview, pp. 17–40. White, S. (2004), ‘Business process modeling notation 1.0, (BPMN)’, http://www.bpmi.org. Wilson, T. D. (2002), ‘The nonsense of ’knowledge management”, Information Research 8(1). Wittgenstein, L. (1961), Tractatus Logico-Philophicus, Routledge. Woods, W. A. (1991), Principles of Semantic Networks: Explorations in the Representation of Knowledge., M. Kaufmann, California, chapter Understanding Subsumption and Taxonomy: A Framework for Progress., pp. 45–94. Zachman, J. A. (1987), ‘A framework for information systems architecture’, IBM Systems Journal 26(3). Zdravkovic, J. & Kabilan, V. (2005a), ‘Enabling business process interoperability using contract workflow models.’, Proceedings of 13th International Conference on Co-operative Information Systems (CooPIS). . Zdravkovic, J. & Kabilan, V. (2005b), ‘Enabling business process interoperability using contract workflow models.’, Proceedings of 13th International Conference on Co-operative Information Systems (CooPIS) .

O A

Appendix

In this section, we present the conceptual models for the INCOTERMS delivery patterns that are an extension to the Sale of Goods Contract models.

A.1 INCOTERMS: Delivery Patterns for Sale of Goods

Sale of Goods business contracts form the domain of interest for our knowledge models. Such legal contracts, pertaining to purchase and sale, cover a wide arena. We chose a smaller domain of interest as a case study, to assess the usability of our proposed O4IS design methodology. We chose to analyze and model the contractual knowledge from a recommended standard of contract patterns ICCs IN- COTERMS (Ramberg 1999). INCOTERMS provide a set of international rules for the interpretation of commonly used trade terms in foreign trade. Frequently parties are unaware of the different trading practices in their respective countries. This can give rise to misunderstandings, disputes, and litigation. In order to remedy this Interna- tional Chamber of Commerce (ICC) first published the Incoterms in 1936. Amende- ments and additions have been subsequently made, the latest being Incoterms 2000. In 1990, Incoterms was revised to adapt the terms to the use of EDI data. INCOTERMS form only a part of the vast contractual knowledge contained in a Sale of Goods contract, as recommended by ICC International Sale of Commercial Goods. These are delivery terms agreed between the two parties involved in a sale of goods business transaction. They are internationally accepted as standardized patterns for delivery terms. In this section, we propose the use of INCOTERMS as a horizontal extension or an individual reusable ontology in the specific domain level of the MTCO. Either the delivery terms of a Sale of Goods contract may refer to one of the INCOTERMS standard codes, or the contracting parties may define their own, as the established business practices. The terms have been grouped in four basically different categories, namely starting with the only term whereby the seller makes the goods available to the buyer at 310 A Appendix the seller’s own premises (the ex works); followed by the second group whereby the seller is called upon to deliver the goods to a carrier appointed by the buyer(FCA, FAS, FOB); continuing with the C terms where the seller has to contract for carriage, but without assuming the risk of loss of exchange or damage to the goods or additional costs due to events occurring after the shipment or dispatch (CFR, CIF, CPT, CIP); and finally the D terms whereby the seller has to bear all costs and risks needed to bring the goods to the country of destination (DAF, DES, DEQ, DDU, DDP). Thus the Incoterms clearly outline the obligations, roles and responsibilities of various actions and counter actions of both the Seller and the Buyer. The Incoterms distribute the obligations between the buyer and the seller. There are thirteen Incoterms in all, all of them discuss the same group of obligations. The distribution between the seller and the buyer, the mode of fulfillment, the place and venue of fulfillment of these obligations is what distinguishes the thirteen Incoterms.

Fig. A.1. INCOTERMS:Obligation to Exchange Goods

The main INCOTERMS concepts are inherited from the sale of goods contract. (ﬁgure 7.13). Figure A.4 gives an overview of the main concepts and we can see that they are inherited from the sale of goods contract. Figure A.3 gives more speciﬁc details as described in the Incoterms, some of the main concepts are summarized below:

• Actor. Two or more parties who participate in the purchase and sale of goods. A.1 INCOTERMS: Delivery Patterns for Sale of Goods 311

• Obligation. An obligation is a promise or commitment made by one party to the other, which is backed up by legal intent to fulfill and uphold the promise. • Role.The part an actor plays in the specific contract (i.e. seller, buyer, etc.). • Goods. Goods are legally defined as commodities or items of all types, expecting services, which are involved in trade or commerce. Goods are characterized by a description, technical specification, type of packaging required, type of cargo etc. • Performance. Every obligation is expected to be fulfilled through the execution of some business, economic or legal action. This expected business behavior is termed as performance. • Delivery Terms. Delivery terms are agreed terms and conditions, which govern the actual process of delivery of goods between the seller and the buyer. • Packaging. In most cases the parties know beforehand which type of packaging is required for the safe carriage of the goods to the destination. As the seller’s obligation to pack the goods may vary depending upon the type and duration of the transport, it has been stipulated that the seller is obliged to pack the goods in the way it is required for the transport. • Inspection of Goods. In many cases the buyer may be advised to arrange for the inspection of goods before, or at the time the goods are handed over by the seller. • Payment Terms. In relation with delivery terms, Sale of Goods includes payment terms, which are expected in exchange for the goods delivered. Though the IN- COTERMS does not go into specific details for the payment terms, the obligation and the performances are outlined. • Customs Clearance: It is normally desirable that the party domiciled in the country where such clearance should take place or at least by somebody acting there on his behalf arranges customs clearance. Thus the Exporter should normally clear the goods for export, while the importer should clear the goods for import. However under some trade terms, The buyer may undertake to clear the goods for export in the seller’s country (Ex Works, F AS) and, in other cases the Seller may undertake to clear the goods for import into the buyer’s country(DEQ and DDP). Needless to say that in these cases the buyer and seller respectively must assume any risk of export and import prohibition. They must also ascertain that a customs clearance performed by a party not domiciled in the country is acceptable to the authorities. • Division of Costs. One of the main aspects to be agreed upon is the cost of delivery and shipping including all incidental costs like export, import, customs etc. The various INCOTERMS differ mainly in the division of costs,division of risks and point of fulfillment of obligations. 312 A Appendix

• Division of Risks. Another aspect on which the choice of the applicable IN- COTERMS is decided is how, when or where the transfer of risks (for loss or damage,ownership etc) should occur.

In order to specify the obligations, roles and responsibilities of different delivery protocols, the INCOTERMS have been grouped in four different categories. In our study we will use the term Ex Works, whereby the seller makes the goods available to the Buyer at the seller’s own premises, to bring the goods to the country of destination. In table A.1, we present a summary Ex Works, in order to elucidate the nature and type of obligations that are present in any such delivery term.

Table A.1. Extract from distribution of obligations in Ex-Works INCOTERMS delivery patterns Obligation Seller Buyer Provision of goods and Yes No Comm. Invoice Delivery Place the goods at the named Take delivery as soon place of delivery on the date or as they have been within the period stipulated. placed at his disposal. Payment of price None Pay the price as provided in the contract. Notice to the buyer Give notice as to when and where Not applicable the goods shall be placed at the buyers disposal. Packaging, marking Provide at his own cost packag- Providing the transport ing as it is required by the circum- modalities and inform- stances relating to the mode of ing the seller of the re- transport, destination etc. Pack- quired packaging. aging is to be appropriately marked. Inspection of goods None Pay the shipment inspection and inspection mandated by the country of exportation.

Some of the main obligations that have been identified in the Incoterms may be seen in figure A.4. In figure A.4 we see the depiction of the main events as they occur in time- ordered sequence for the Ex Works delivery pattern. The execution begins by the buyer placing an order. The figure also shows the time period that is available with the buyer in which he has to make arrangements for the carrier and also notify the seller of the same. A.1 INCOTERMS: Delivery Patterns for Sale of Goods 313 Overview of common features of the INCOTERMS delivery patterns Fig. A.2. 314 A Appendix i.A.3. Fig. NOEM:biaint xhneGoods Exchange to INCOTERMS:Obligation A.1 INCOTERMS: Delivery Patterns for Sale of Goods 315 - Ex Works: A typical case scenario for contract execution between seller and buyer Fig. A.4. 316 A Appendix

A.2 Sample Contract Analysis

Let us analyze a typical contract sample between a Seller and a Buyer (Copy is attached as given in section A.3) where the two parties agree to exchange goods for money. We see that the contract type is that of a Sale of Goods. Accordingly, we compare with the shared domain contract type specific ontology for commercial sale of goods. Principal concepts like buyer, seller, their identification, addresses etc are readily identified. Help is available from the Sale of Goods ontology, which gives us the nature and type of obligations usually associated with this type of contracts.

A.2.1 Phase 1: Contract Type Identiﬁcation

Input: The given business contract, proposed MTCO. Step: By parsing through the contract text we should be able to judge the contract type as it would most often be written on it. Output: Sale of Goods Contract Type, ICC ’s Sale of International Goods Contract Ontology can be used as the reference ontology.

A.2.2 Phase 2: Contract Instance MetaData

Input: The agreed contract, the MTCO, the O4IS design methdology, USP2 Design, and the SARs. Output: We have presented a paragraph by paragraph textual analysis results in (Kabilan 2003). Here we just summarize the end results of the iterative step by step analysis to get the data for the semantic concept view of the given contract as :

A.2.3 Phase 3: Obligation Performance Events Identiﬁcation

Input: Meta-data from Phase 2. Output: List of obligations, their types and their actors/roles. Process:

Step 1: The next step is to list all the obligations explicitly or inherently implied in the contract. Tips: Most of the obligations would already have been identiﬁed in phase 2 themselves. In this step, the user would need to re-use his extracted knowledge. Some obligations may not be explicitly stated but would have been implied based on contemporary business practices. For example, the seller is responsible for loading the goods on to the carrier, whenever the carrier is picking up the goods at the seller’s premises. In our case scenario, the some of the obligations are: Step 2: Identify for each obligation, who is the owner and who is the ownee. A.2 Sample Contract Analysis 317

Table A.2. Phase2- MetaData from Given Contract Example Concept Information Extracted Contract Type Sale of Goods Contract type Actor1 ABC Computers Incorporated Ltd Role1 Seller Address for Actor 1 Viderogatan 17, Kista, Sweden Actor 2 Stock and Financial Movers AB Address for Actor 2 Strandvagen¨ 2,Stockholm, Sweden Role2 Buyer Consideration Computers Speciﬁcation DELL PC Dimension 4550 Intel Pentium 4 processor 333 Mhz Contract date 12th NOV 2004 Primary Obligation of Transfer and delivery of goods Seller Primary Obligation of Receive and pay for goods. Buyer Performance Delivery Performed By Seller Place of delivery Seller Date and time Seller Delivery fulﬁlled when Seller Performance Pay Performed By Buyer Place At the place of delivery Date and time At the time of delivery Right to inspect Owner is Buyer. Performance Inspect goods, notify seller. Performed By Buyer Time Period Within 15 days after delivery receipt. Ownee Seller

Table A.3. Phase 3- List of Obligations Obligations Obligation to deliver Obligation to pay Obligation to insure the goods Obligation to accept the goods Obligation to pay penalty Obligation to package the goods Obligation to arrange for carrier for transporting the goods. 318 A Appendix

Tips: Find out who has to perform the obligation, and who is the beneﬁciary or claimant for the same. Most of the standard obligation owner and ownee could be found in the multi tier ontology, but the actual speciﬁcation can only be found from the contract instance, which could be different from recommended models (which have been the source for the shared buy sell contract conceptual models). Hence, the user is recommended to refer to the ontology as a guide to determine the exact information from his contract. In the case contract, we see that:

Table A.4. Phase 3- Obligation Owner and Ownee Obligation Owner Ownee Obligation to deliver Buyer Seller Obligation to pay Seller Buyer Obligation to insure the goods Buyer Seller Obligation to accept the good Seller Buyer Obligation to pay penalty for late Buyer Seller delivery, delivery unsatisfactory, delivery failure Obligation to arrange carrier for Buyer Seller transportation of goods (if buyer is the performer) Obligation to arrange carrier for Seller (performance deferred to Buyer transportation of goods (if seller Seller), Primary Obligation still is the performer) rests with Buyer Obligation to package the goods Seller Buyer

Step 3:

• Identify for each obligation, the obligation type from the MTCO. • Traverse the associations to get the related reciprocal, conditional, reconciliatory or secondary obligation.

Tips: Look up the obligation in the MTCO. In case of shared ontology for a buy sell contract type, the user will be able to directly look up ‘obligation to pay’ or ‘obligation to deliver’. From the MTCO, the user will get the information regarding the nature of obligation (whether it is business obligation, a monetary obligation or a legal obligation or a combination of these), obligation type (whether it is the primary obligation, does it have any related reciprocal or conditional or secondary obligation etc). The obligation type information is useful for sorting and arranging the obligations in the order of their execution and their sequence within the business time frame. Some of the identiﬁed obligations, their types and the associated obligations as well as the identiﬁed obligation Owner and Ownee is summed up in table A.5: A.2 Sample Contract Analysis 319

Table A.5. Phase 3- Obligations Summarized Obligation Owner Ownee Obligation Nature of Obli- Type gation Obligation to deliver Buyer Seller Primary Legal, business Obligation to pay Seller Buyer Primary Monetary, legal Obligation to accept Seller Buyer Primary and Business the goods Secondary Obligation to pack- Seller Buyer Secondary Business age the goods Obligation to pay Buyer Seller Reconciliatory Monetary, Legal penalty for late delivery, delivery unsatisfactory, delivery failure Obligation to arrange Seller (perfor- Buyer Conditional Moral carrier for transporta- mance deferred (upon request tion of goods (if seller to Seller), Pri- from Buyer) is the performer) mary Obligation still rests with Buyer Obligation to ar- Buyer Seller Secondary Business range carrier for transportation of goods (if buyer is the performer)

A.2.4 Phase 4: Obligation, Performance, Non-Performance Interrelationships

Input: List of obligations from Phase 3 (table A.5 and table A.3) Output: Unordered list of performance events corresponding to each obligation. Process:

Step 1: Look up the main performance needed to fulfil each obligation, as identified in the previous phase, from the MTCO. Step 2: Deduce the business activities required to execute that performance successfully. Tips: In most cases the obligation statement gives an indication of the required performance from the ownee. The obligation Ownee is the one who has to be the performer. Like, the obligation to deliver clearly indicates that the seller has to deliver the goods. If we accept ‘deliver goods’ as the performance event required for fulfilling this obligation, we see from the internal business process model of a seller, that in order to be able to deliver the goods, he may need to make the goods first. Maybe to make the goods, he needs to get the raw materials from his supplier. That could mean that he would need to place an order with his supplier and so on. Such 320 A Appendix deductions can be made from the basic required event by the business organization (or business process manager etc). A good contract should be able to give all required information regarding the performance events to be executed. Any ambiguity left in the specification could lead to different interpretations and finally to non-compliance to the contract terms. The internal business process modeling of the organizations is currently beyond the scope of this guideline. The guideline assumes and adopts common business process models as recommended strategies. In the above example, deductions for required sequence of business activities on the seller’s side are inferred from standard business models like the supply value chain, other enterprise ontologies like that of TOVE (Fox 1992), Enterprise Ontology (Uschold et al. 1995) or standards like ebXML (OASIS 2002), BPSS(Business Process Schema Specifications, Business Process Work Sheets) etc.

Table A.6. Phase 4- Deduced Performance Activities Obligation Possible List of Performance Events Ship goods Deliver goods (basic performance) Load goods (extracted from internal workflow) Mark goods (from legal regulation which needs Obligation to Deliver goods to be marked for particular buyer) Get raw materials (extracted from internal workflow) Arrange carrier (implied from contract) Quality assurance of goods (legal requirement that goods should conform to specification) Pack goods Get information of mode of transport Assess duration of transportation Obligation to package Assess type of packaging required Get packaging material Pack goods (basic performance) Pay for goods (basic performance) Make arrangements with bank Receive goods Obligation to pay Inspect Goods Send Acceptance Notify seller of any discrepancy

Step 3:

• The user has now to order the obligations. The ordering of the obligations is recommended on the order of the nature of the obligation. Sort by the obligation ownee. A.2 Sample Contract Analysis 321

• List all the rights of individual parties at the end. However they need not be ordered sequentially since some of their execution need not be compulsory or no time ordered choreography might be interpreted. • List any Prohibitions too, if stated.

Tips: The primary obligations ﬁrst, then the nested or secondary obligation (obligations which are part of the primary obligation), followed by conditional obligations (obligations which may be triggered only if certain conditions arise and are not enforced by default, they are mostly cases like when due to non performance some particular right of the other party is enforced etc). Conditional obligations may also be treated on par with nested secondary obligations as they could be fulﬁlled as a necessary sub- unit of the main primary obligation itself. Help may also be taken from the list of performance activities (table 5), to judge the nature of obligation.

Table A.7. Phase 4- Seller and Buyer’s Obligations Seller’s Obligations Buyer’s Obligations Obligation to deliver Obligation to pay Obligation to package Obligation to arrange carrier Obligation To Ship Obligation to inform seller about carrier Obligation to Transfer ownership Obligation to accept goods Obligation to Remedy Right to inspect Right to cancel Right to remedy

Step4: Separate the list of deduced activities and obligations by the performer. Tips: Each list would ultimately lead to the business activity workﬂow as per the contract requirement for each of the organization involved. Step 5: Now order the activities sequentially in the order (with respect to time and/or logic) they should be executed. Some information should be available from the contract, which would help in the ordering. Like in Paragraph 5, we see that the buyer would pay after he receives the goods or in Paragraph 9 that the buyer should inspect the goods and then notify the seller before a set number of days, if he wishes to claim compensation. Step 6: Note down any pre conditions or rules or policies, which need to be checked or enforced for any of the listed activities. Along with a rough idea for the order of execution, the contract also provides information regarding the conditions for execution of the same activities. For example, the buyer can cancel his order as long as the seller has not already dispatched it. That implies that the action ‘cancel order’ by the buyer has a qualifying condition that the seller’s action ‘ship goods’ 322 A Appendix must not have occurred. These conditions need to be in built as the boundary parameters within the CWM. The user is advised to note these pre-conditions and sketch them in roughly in the CWM.

Table A.8. Phase 4- Buyer and Seller’s Performances: In Temporal Order Seller’s Performance Events Buyer’s Performance Evensts Send receipt acknowledgement Send Purchase Order for PO Get Raw materials Receive acknowledgment Make PC Cancel order (has pre condition can occur only till ship goods has not occurred) Pack PC (has pre condition: Arrange carrier Should have received info about mode of transport from buyer before this) Ship PC Inform seller of carrier choice Receive delivery receipt Receive goods Send Invoice (has time bounded Inspect goods condition Send invoice on delivery receipt or after 15 days from Delivery accepted at buyer.) Send delivery receipt Receive invoice Make payment

Step 7: Break up each listed obligation (table A.7, table A.8) into the states through which each individual obligation will pass. Tips: From the MTCO, the user should be getting a picture of the different states an obligation would cycle through, Inactive, active, pending, fulfilled or canceled. The user will also get additional information as the when the state change of each obligation will occur. This would be typically on execution of a related performance. The performance, which triggers the obligation from inactive to active, is connected to the obligation state. A state-activity diagram can be sketched for each role player. Step 8: Identify which activity is related to which obligation. Tips: Either performer may execute the activities. (Either the seller or buyer). Ex: The obligation to deliver for the seller is activated when the order sent by the buyer reaches the seller. The obligation could be pending when the seller has sent the delivery but is waiting for the buyer to accept. But note that the seller’s obligation to bear the risk for damage is fulfilled once the delivery has been made to the Buyers premises. After the buyer inspects the goods or the time period lapses, the seller’s obligation to deliver is fulfilled. A.2 Sample Contract Analysis 323

Step 9: Keep the same order as listed in previous phases and now insert the identified states, and draw a simple flow diagram, listing all the obligations, their states, related performance activities for each role player, seller and buyer. Tips: The user may put the two sequences side by side on the same vertical or horizontal time scale to get a clearer picture of the flow of control and execution of the contract.

Fig. A.5. Obligation and Performance Events in Time Ordered Sequence

But in the contract workflow pattern, the two business activity threads are not isolated but intertwined. Activity A in one workflow may be triggered or fulfilled by some other Activity B in the other workflow or vice versa. Similarly Obligation Y may be state changed due to activity B executed by the other workflow. A CWM essentially models a rough outline for the flow of business processes and fulfilment conditions and patterns for the obligations stipulated in a contract. At the end of this phase, the user is ready with all the concepts and object blocks to deduce the CWM. Once the CWM is deduced, the business activity workflow depicted for each organization should be the recommended workflow for contract compliance. The derived business workflow would probably not be complete but only an indicative guide for recommended business process workflow as illustrated in figure A.5. Internal business process activities may not be captured and only qualitative analysis and interpretations of required business activities may be proposed.

A.2.5 Phase 5: Optional mapping to existing Business Process ﬂows

This phase is an optional stage and can be used to map to existing internal business process ﬂows of the business organizations involved in the contract. Alternatively 324 A Appendix one can also map to other established process or enterprise ontologies like TOVE or Enterprise Ontology or standards like the Business Process Worksheets within the ebXML etc. For simplicity sake, detailed analysis on this phase is excluded from this thesis document.

A.2.6 Phase 6: Contract Workﬂow Model for sample contract

Input: figure A.5 and information tabulated in tables A.5 to A.8. Output: simple contract workflow using EPC notations as shown in figure A.6. Process: Step1: The user has now to draw separate CWM diagram for each of the parties involved. He should translate the rough sketch from figure 30 in to the EPC notation, by mapping obligations to functions and performance events to events. Step2: Now the user connects the events and functions blocks by the appropriate logical connectors, AND, OR or XOR. An AND connector is to be used when the all the paths of the CWM is to be executed. Like the seller must make the goods as well as have the carrier information ready before he can ship the goods. An OR connector is to be used when there are choices or options to be made. In the CWM, an OR usually denotes one or more choices to be made. A XOR connector is to be made when one and only one choice from a multiple set of choices is to be made. Now the user has deduced the CWM from the contract instance. Figure A.6 shows an illustration of an epc diagram for the ex-works Incoterms delivery pattern. A.2 Sample Contract Analysis 325

Fig. A.6. Deduced Contract Workﬂow Model using EPC Diagram 326 A Appendix

A.3 Sample Contract

CONTRACT FOR SALE OF GOODS 1. Agreement made and entered into this [12th Nov 2004], by and between [ABC Computers Incorporated Ltd], of [Osterogatan¨ 17, Kista, Sweden], herein referred to as ‘Seller’, and [Stock and Financial Movers AB], of [Strandvagen¨ 2,Stockholm, Sweden], herein referred to as ‘Buyer’. 2. Seller hereby agrees to transfer and deliver to buyer, within 30 days from the date of order receipt, the following goods: DELL PC Dimension 4550, Intel Pentium 4 processor, 333 MHz DDR SDRAM desk- tops conforming to the technical specifications. Product details specified separately. 3. Buyer agrees to accept the goods and pay for them in accordance with the terms of the contract. 4. Buyer and Seller agree that identification shall not be deemed to have been made until both parties have agreed that the goods in question are to be appropri- ated and fulfil the requirements of performance of said contract with the Buyer. 5. Buyer agrees to pay for the goods at the time they are delivered and at the place where he receives said goods. 6. Goods shall be deemed received by buyer when delivered to address of buyer as herein described. 7. Until such time as said buyer has received goods, all risk of loss from any casualty to said goods shall be on seller. 8. Seller warrants that the goods are now free from any security interest, other lien or encumbrance, that they shall be free from it at the time of Delivery, and that he neither knows nor has reason to know of any outstanding title or claim of title hostile to his rights in the goods. 9. Buyer has the right to examine the goods on arrival and has [7] days to notify seller of any claim for damages on account of the condition, grade or quality of the goods. That said notice must specifically set forth the basis of his claim, and that his failure to either notice seller within the stipulated period of time or to set forth specifically the basis of his claim will constitute irrevocable acceptance of the goods. 10. This agreement has been executed in duplicate, whereby both Buyer and Seller have retained one copy each, on [12th Nov 2004]. ———— ————

[Signatures] DEPARTMENT OF COMPUTER AND SYSTEMS SCIENCES Stockholm University/KTH www.dsv.su.se/eng/publikationer/index.html Ph.D. Theses:

No 91-004 Olsson, Jan An Architecture for Diagnostic Reasoning Based on Causal Models No 93-008 Orci, Terttu Temporal Reasoning and Data Bases No 93-009 Eriksson, Lars-Henrik Finitary Partial Definitions and General Logic No 93-010 Johannesson, Paul Schema Integration Schema Translation, and Interoperability in Federated Informa- tion Systems No 93-018 Wangler, Benkt Contributions to Functional Requirements Modelling No 93-019 Boman, Magnus A Logical Specification for Federated Information Systems No 93-024 Rayner, Manny Abductive Equivalential Translation and its Application to Natural-Language Database Interfacing No 93-025 Idestam-Almquist, Peter Generalization of Clauses No 93-026 Aronsson, Martin GCLA: The Design, Use, and Implementation of a Program Development No 93-029 Bostrom,¨ Henrik Explanation-Based Transformation of Logic programs No 94-001 Samuelsson, Christer Fast Natural Language Parsing Using Explanation-Based Learning No 94-003 Ekenberg, Love Decision Support in Numerically Imprecise Domains No 94-004 Kowalski, Stewart IT Insecurity: A Multi-disciplinary Inquiry No 94-007 Asker, Lars Partial Explanations as a Basis for Learning No 94-009 Kjellin, Harald A Method for Acquiring and Refining Knowledge in Weak Theory Domains No 94-011 Britts, Stefan Object Database Design No 94-014 Kilander, Fredrik Incremental Conceptual Clustering in an On-Line Application 328 A Appendix

No 95-019 Song, Wei Schema Integration: - Principles, Methods and Applications No 95-050 Johansson, Anna-Lena Logic Program Synthesis Using Schema Instantiation in an Interactive Environment No 95-054 Stensmo, Magnus Adaptive Automated Diagnosis No 96-004 Wærn, Annika Recognising Human Plans: Issues for Plan Recognition in Human - Computer Inter- action No 96-006 Orsvarn,¨ Klas Knowledge Modelling with Libraries of Task Decomposition Methods No 96-008 Dalianis, Hercules Concise Natural Language Generation from Formal Specifications No 96-009 Holm, Peter On the Design and Usage of Information Technology and the Structuring of Commu- nication and Work No 96-018 Hoök,¨ Kristina A Glass Box Approach to Adaptive Hypermedia No 96-021 Yngstrom,¨ Louise A Systemic-Holistic Approach to Academic Programmes in IT Security No 97-005 Wohed, Rolf A Language for Enterprise and Information System Modelling No 97-008 Gamback,¨ Bjorn¨ Processing Swedish Sentences: A Unification-Based Grammar and Some Applica- tions No 97-010 Kapidzic Cicovic, Nada Extended Certificate Management System: Design and Protocols No 97-011 Danielson, Mats Computational Decision Analysis No 97-012 Wijkman, Pierre Contributions to Evolutionary Computation No 97-017 Zhang, Ying Multi-Temporal Database Management with a Visual Query Interface No 98-001 Essler, Ulf Analyzing Groupware Adoption: A Framework and Three Case Studies in Lotus Notes Deployment No 98-008 Koistinen, Jari Contributions in Distributed Object Systems Engineering No 99-009 Hakkarainen, Sari Dynamic Aspects and Semantic Enrichment in Schema Comparison A.3 Sample Contract 329

No 99-015 Magnusson, Christer Hedging Shareholder Value in an IT dependent Business society - the Framework BRITS No 00-004 Verhagen, Henricus Norm Autonomous Agents No 00-006 Wohed, Petia Schema Quality, Schema Enrichment, and Reuse in Information Systems Analysis No 01-001 Hokenhammar,¨ Peter Integrerad Bestallningsprocess¨ vid Datasystemutveckling No 01-008 von Schéele, Fabian Controlling Time and Communication in Service Economy No 01-015 Kajko-Mattsson, Mira Corrective Maintenance Maturity Model: Problem Management No 01-019 Stirna, Janis The Influence of Intentional and Situational Factors on Enterprise Modelling Tool Acquisition in Organisations No 01-020 Persson, Anne Enterprise Modelling in Practice: Situational Factors and their Influence on Adopting a Participative Approach No 02-003 Sneiders, Eriks Automated Question Answering: Template-Based Approach No 02-005 Eineborg, Martin Inductive Logic Programming for Part-of-Speech Tagging No 02-006 Bider, Ilia State-Oriented Business Process Modelling: Principles, Theory and Practice No 02-007 Malmberg, Ake˚ Notations Supporting Knowledge Acquisition from Multiple Sources No 02-012 Mannikk¨ o-Barbutiu,¨ Sirkku SENIOR CYBORGS- About Appropriation of Personal Computers Among Some Swedish Elderly People No 02-028 Brash, Danny Reuse in Information Systems Development: A Qualitative Inquiry No 03-001 Svensson, Martin Designing, Defining and Evaluating Social Navigation No 03-002 Espinoza, Fredrik Individual Service Provisioning No 03-004 Eriksson-Granskog, Agneta General Metarules for Interactive Modular Construction of Natural Deduction Proofs No 03-005 De Zoysa, T. Nandika Kasun A Model of Security Architecture for Multi-Party Transactions 330 A Appendix

No 03-008 Tholander, Jakob Constructing to Learn, Learning to Construct - Studies on Computational Tools for Learning No 03-009 Karlgren, Klas Mastering the Use of Gobbledygook - Studies on the Development of Expertise Through Exposure to Experienced Practitioners’ Deliberation on Authentic Problems No 03-014 Kjellman, Arne Constructive Systems Science - The Only Remaining Alternative? No 03-015 Rydberg Fa˚ hræus, Eva A Triple Helix of Learning Processes - How to cultivate learning, communication and collaboration among distance-education learners No 03-016 Zemke, Stefan Data Mining for Prediction - Financial Series Case No 04-002 Hulth, Anette Combining Machine Learning and Natural Language Processing for Automatic Key- word Extraction No 04-011 Jayaweera, Prasad M. A Uniﬁed Framework for e-Commerce Systems Development: Business Process Pat- terns Perspective No 04-013 Soderstr¨ om,¨ Eva B2B Standards Implementation: Issues and Solutions No 04-014 Backlund, Per Development Process Knowledge Transfer through Method Adaptation, Implemen- tation, and Use No 05-003 Davies, Guy Mapping and Integration of Schema Representations of Component Speciﬁcations No 05-004 Jansson, Eva Working Together when Being Apart - An Analysis of Distributed Collaborative Work through ICT from an Organizational and Psychosocial Perspective No 05-007 Coster,¨ Rickard Algorithms and Representations for Personalised Information Access No 05-009 Ciobanu Morogan, Matei Security System for Ad-hoc Wireless Networks based on Generic Secure Objects No 05-010 Bjorck,¨ Fredrik Discovering Information Security Management No 05-012 Brouwers, Lisa Microsimulation Models for Disaster Policy Making No 05-014 Nackros,¨ Kjell Visualising Security through Computer Games Investigating Game-Based Instruction in ICT Security: an Experimental approach A.3 Sample Contract 331

No 05-015 Bylund, Markus A Design Rationale for Pervasive Computing No 05-016 Strand, Mattias External Data Incorporation into Data Warehouses No 05-020 Casmir, Respickius A Dynamic and Adaptive Information Security Awareness (DAISA) approach No 05-021 Svensson, Harald Developing Support for Agile and Plan-Driven Methods No 05-022 Rudstrom,¨ Asa˚ Co-Construction of Hybrid Spaces No 06-005 Lindgren, Tony Methods of Solving Conﬂicts among Induced Rules No 06-009 Wrigstad, Tobias Owner-Based Alias Management No 06-011 Skoglund, Mats Curbing Dependencies in Software Evolution No 06-012 Zdravkovic, Jelena Process Integration for the Extended Enterprise No 06-013 Olsson Neve, Theresia Capturing and Analysing Emotions to Support Organisational Learning: The Affect Based Learning Matrix No 06-016 Chaula, Job Asheri A Socio-Technical Analysis of Information Systems Security Assurance A Case Study for Effective Assurance No 06-017 Tarimo, Charles N. ICT Security Readiness Checklist for Developing Countries: A Social-Technical Ap- proach No 06-020 Kiﬂe Gelan, Mengistu A Theoretical Model for Telemedicine - Social and Value Outcomes in Sub-Saharan Africa No 07-001 Fernaeus, Ylva Let’s Make a Digital Patchwork Designing for Children’s Creative Play with Program- ming Materials No 07-003 Bakari, Jabiri Kuwe A Holistic Approach for Managing ICT Security in Non-Commercial Organisations A Case Study in a Developing Country No 07-004 Sundholm, Hillevi Spaces within Spaces: The Construction of a Collaborative Reality No 07-005 Hansson, Karin A Framework for Evaluation of Flood Management Strategies 332 A Appendix

No 07-007 Aidemark, Jan Strategic Planning of Knowledge Management Systems - A Problem Exploration Ap- proach No 07-009 Jonsson, Martin Sensing and Making Sense Designing Middleware for Context Aware Computing