Ontology for InformationSystems (O4IS) Design
MethodologyConceptualizing, Designing and Representing
Domain Ontologies
Vandana Kabilan
October 2007.
A Dissertation submitted to
The Royal Institute of Technology
in partial fullfillment 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
infinite 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 refinement 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 na-
ture. It’s a system for testing your thoughts against the universe, and seeing
whether they match.
– Isaac Asimov. (1920 – 1992) Russian-U.S. science-fiction author.
VII
Dedicated to the three KAs of my life: Kabilan, Rithika and Kavin.
IX
Abstract. Globalization has opened new frontiers for business enterprises and human com-
munication. There is an information explosion that necessitates huge amounts of informa-
tion to be speedily processed and acted upon. Information Systems aim to facilitate human
decision-making by retrieving context-sensitive information, making implicit knowledge ex-
plicit 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 ontol-
ogy 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 conceptu-
alization of the semantics and pragmatics of a domain. We further propose a set of Semantic
Analysis Representations as conceptual analysis patterns for semantic relationship identifica-
tion. 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.
XI
Acknowledgement. It has been an enlightening journey into unknown frontiers, learning to
solve new challenges, and finding 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 construc-
tive criticisms.
Last, but not the least, this research would never have become a reality, without the sup-
port 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 flicker.
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 Unified 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 Identification 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 Specific 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 Protege 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 Protege . . . . . . . . . . . . . . . . . . . . . . . 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 Workflow Model using EPC Diagram . . . . . . . . . . . . . 325
List of Tables
2.1 Definitions 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
v 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-Perez, 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 informa-
tion integration. But, what is ontology within Information Systems? Simply put it is
nothing but a:
“specification of a representational vocabulary for a shared domain of
discourse– definitions of classes, relations, functions and other objects.”
–Gruber (1993a).
A key use of ontology is to share information between people, databases and appli-
cations. 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 re-
search.
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 fields 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 definition of Information Systems.
1.1.1 Information Systems
For this research we uphold the definition(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, oper-
ations 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 de-
cision 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 mod-
eling. However, we analyze Information Systems as a field 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 infor-
mation 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 analy-
sis 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 figure 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 figure 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 on-
tology 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 on-
tology 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 ontolo-
gies” that are built by combining philosophical approach with pragmatic objec-
tives. 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 ontolo-
gies 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 fig-
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 grammaralong with a set of procedures, conceptual-modeling methods that can guide the In-
formation Systems designer in building conceptual schemas, viz conceptual-modelingscript. 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 frame-
work 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 mod-
els 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 specific 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 informa-
tion 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 con-
ceptual 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; se-
mantics, 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, communi-
cation 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 definitions of key terms used in conceptual mod-
eling, 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 specific
problem is called a conceptual model of the domain.
1.3 Research Motivation: Information systems need ontology 7
• The definition of a concept describes its intention. Intensionality qualities a con-
cept 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 definitions 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 forInformation Systems. Our scope of interest revolves around how to create an
ontology that is to be used for a specific 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 field 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 infer-
encing capability of ontology is being utilized in Information Systems. But, complete
automation is not the ultimate goal since we would always have human involve-
ment in an information system. However, emerging technologies like Semantic Web
endeavor to make the web machine-readable, for providing the human consumers a
more efficient service, like context-aware information retrieval. Some other emerg-
ing 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 efficiently, speedily and accurately. Now with the onset of Se-
mantic Web technologies, the shift from data processing to knowledge man-
agement is subtle yet inevitable. With this comes a shift in the way we visual-
ize, 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 maga-
zine (December 2006) has voted the Internet user as the most influential person
of 2006. The Internet has become the medium of social communication, express-
ing 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 ex-
ample, 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 enter-
prise 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 (dis-
cussed 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 efficiently satisfy the need of the changing market, simply by processing
chunks of data. They need to support higher level of reasoning and provide intel-
ligent 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 scientific 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, FP6508011, www.interop-noe.org
10 1 Introduction
Fig. 1.5. Current Situation of Ontology Design and Use in Information Systems: Based onMITRE 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 com-
mercial 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 specific purpose. The domain knowledge to be captured in such
cases involves not only descriptive definitions 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.org3 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 ex-
plicit, that includes the behavioral, business constraints and operational knowl-
edge 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 compre-
hensive 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 method-
ologies 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-Perez & 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 cur-
rent state-of-the art ontology design methodologies:
• Do not prescribe sufficiently how to handle and merge the functional require-
ments 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 Language5 Semantic Web Rule Language
12 1 Introduction
• Overlap each other in some design phases but they are not individually com-
prehensive, 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 knowl-
edge, 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 de-
signer 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 tech-
nology – To make the transition from being an innovative scientific research theory
(ontology) in to an acceptable, successful and useful technology. Apropos our ear-
lier 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 re-
search 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 onthe 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 rela-
tionships. 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 de-
sign 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 asontologies that are to be used in Information Systems?
2. How should domain ontologies (of social domains) be designed, considering thefunctional requirements of Information Systems, including design choices that anIS designer should make with regard to architecture, development strategy, repre-sentation language, and selection of tools?
3. For what purposes may an ontology of social domains designed for InformationSystems be used?
1.6 Goal
To respond to the question how should the semantic and pragmatic aspects of socialdomains be represented, we delve into the field 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 method-
ologies, relevant literature from linguistics, AI, philosophy and Logic that help in
analysis of extensional and intensional representations. Thereafter, we need a de-
sign 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 stud-
ies 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 focuson their semantic and pragmatic aspects.
• To demonstrate the usefulness of this methodology for designing ontologies that canbe 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 con-
sisting 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 methodol-
ogy.
Domain Ontologies: A layman’s definition of domain ontology maybe given as:
A domain ontology (or domain-specific ontology) models a specific domain,
or part of the world. It represents the particular meanings of terms as they
apply to that domain.
A more theoretical definition 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 partic-
ular 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 fac-
tor 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 ontolo-
gies 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 under-
standing 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 de-
signers, business managers and decision makers (human designers and users), we
focus more on the knowledge capture and representation aspect than the formal en-
coding 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 specifications 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 re-
search - design science and behavioral science. Behavioral science paradigm devel-
ops and verifies 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 capabili-
ties 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 ‘con-
structs’, ‘models’, ‘methods’ and ‘instantiations’. Artifacts are built to solve given re-
search 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 understand-
ing. 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 con-
structs defined. The difference between routine engineering solutions like building
software applications to solve enterprise management issues and that of design sci-
ence, 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 concep-
tual 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 re-
search 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 demon-
strate 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 objec-
tives for the proposed solution to the identified problem. To quote Peffers - “The
1.9 Research Methodology 17
Fig.
1.6.
Des
ign
Scie
nce
Res
earc
hPr
oces
sM
odel
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 ar-
tifact. 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, prac-
ticing 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 over-
all 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 un-
der sections 1.4 to 1.7. The design methodology is based on literature study, there-
after 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 first level of eval-
uation 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 pro-
cess 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 field. This is achieved through
joint research with other researchers, publishing scientific articles in appropriate
circles and also reviews by domain experts and end users for proposed ontolo-
gies.
2. However, the main assessment of the usability,viability of the proposed method-
ology, is to be achieved by applying the same on different case studies, each re-
lating 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 first 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 busi-
ness 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 rang-
ing from interoperability of enterprise systems, modeling of contract compliant
business process flows are proposed.
• The second case study delves into the domain of military modeling and simu-
lation. 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 pragmat-
ics 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 devel-
opment 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 as-
pects 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 meth-
ods, 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 visual-
ized 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 illus-
trated in figure 1.3 and discussed earlier, our O4IS design methodology puts forward
a conceptual modeling context (ontologies for IS), prescribes a conceptual model-
ing 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 briefly discuss an overview of O4IS design methodology and its related artifacts
(as can be seen in figure 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 de-
cide what kind of physical or logical architecture is suitable for our proposed
domain ontology. For the logical architecture we propose a multiple layered ar-
chitecture for the domain conceptualization. (Details in section 5.3)
• G4: Choose ontology development approach: We choose the appropriate de-
velopment 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 seman-
tic 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 repre-
sentation 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 includ-
ing 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 infor-
mation 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 ontol-
ogy needs to be tested in the targeted application domain. The utility is to be
assessed. The contents need to be verified 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 on-
tologies 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 chap-
ter 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 busi-
ness contract risk assessment and evaluation. We provide a summary in sec-
tion 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 theoreti-
cal 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 ongo-
ing 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 pre-
scriptive 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 identifi-
cation 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 necessi-
tates 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 knowledgein 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 anontology 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 de-
sign. 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 design-
ing 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 conceptual-
ization via the Unified Semantic Procedural Pragmatic (USP2) Design is presented
in chapter 6.
Chapter 2 :KM, IS Design
Chapter 3:Ontology
Related Research
Proposed Design
Chapter 5: Ontologyfor InformationSystems DesignMethodology
Chapter 6:Unified Semantic
Procedural PragmaticDesign
Chapter 4 : ConceptualModeling
Chapter 7: Multi TierContract Ontology
Chapter 8 : DefenceConceptual ModelingFramework: Ontology
Case Studies
Chapter 9:Discussion of Results
Chapter 1:Introduction
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 dis-
cussed 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 specific applications, as shall be discussed in chapter 8
and chapter 7.
A penultimate chapter 9 assesses the key results and reflects 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 scientific publications related to this thesis. I have been
the first author in all except those where it is otherwise mentioned. With each pub-
lication 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 com-
mon 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 re-
ferred 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 require-
ments for our proposed O4IS design methodology.
5. Jelena Zdravkovic, Vandana Kabilan. Enabling Business Process Interoperability
Using Contract Workflow 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 workflow, and the case scenarios.
6. Vandana Kabilan, Contract Workflow 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 Workflow 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-
flow 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 Unified 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 first 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 first 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.
v 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 informa-
tion 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 re-
search from ontologies in Information Systems and finally in chapter 4, we summa-
rize 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 defined 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) defines:
“Information as that collection of data, which, when presented in a par-
ticular 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 under-
take a particular activity or make a particular decision”
3. Knowledge: Is the application of data and information; answers “how” ques-
tions. Knowledge consists of specialized facts, theories, procedures, and relation-
ships 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 situ-
ation, 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 figure 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 defined 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 mech-
anism 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 con-
stitute an Information System.
As such, humans form the central pivotal key-pin without which information sys-
tems should cease to function. This differentiates information systems from artificial
intelligence systems, which are aimed to operate and function automatically withouthuman 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 anddisseminates information in an organization; a system that accepts dataresources as input and processes them into information products asoutput; a system that uses the resources of hardware, software and peo-ple to perform input, processing, output, storage and control activitiesthat transform data resources into information products; a purposefullydesigned 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 ev-eryday needs.– Key Terminology, Computer and Information Technology(Web Resource)Any equipment or interconnected system or subsystems of equipmentthat is used in the automatic acquisition, storage, manipulation, man-agement, movement, control, display, switching, interchange, trans-mission, or reception of data and that includes computer software,firmware, and hardware. Included are computers, word processing sys-tems, networks, or other electronic information handling systems andassociated equipment. –Information Assurance Terminology,IASO certi-fication course,School of Information Technology. (Web Resource)In Information Systems, an information system consists of three com-ponents: human, task, application system. In this view, informationis defined in terms of the three levels of semiotics. Data which canbe automatically processed by the application system corresponds tothe syntax-level. In the context of an individual who interprets thedata they become information, which correspond to the semantic-level.Information becomes knowledge when an individual knows (under-stands) and evaluates the information (e.g., for a specific task). Thiscorresponds to the pragmatic-level. – Information Systems. (Web Re-source)An information system is a set of interacting artifacts and human ac-tivities that performs one or more functions involving the handling ofdata and information, including data collection, creation, editing, pro-cessing 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 knowl-
edge 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 specific 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 final 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 first written.
The Decision Support Systems Power (1995) glossary defines knowledge as:
“Knowledge refers to what one knows and understands. Knowledge is some-
times 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 knowl-
edge 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 definitions for Meta-data, taxonomy, the-
saurus, ontology, and knowledge base has been given by Victor Lombardi (2003) on
the online article. He has defined 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 defined as:
“A collection of stored facts, heuristics and models that can be used for prob-
lem solving.”
The schema and classification 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 sec-
tion 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 benefit from this
understanding and is a relevant issue to human and machine- based knowledge
systems. Malhotra has also collected a set of varying definitions for knowledge man-
agement, some of the more interesting ones are listed below:
2.3 Knowledge Management 37
• “The process of collecting,organizing, classifying and disseminating infor-
mation 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 avail-
able important know-how, wherever, and whenever needed. This includes
processes, procedures, patents, reference works, formulas, best practices,
forecasts and fixes.”– 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 hu-
mans understand and process information in its different contextualities and mean-
ings 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 disci-
pline, where the specialist extracts the end users requirements and translates
them into specifications 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 addi-
tion 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 artificial 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 artificial 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 typ-
ically 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-
fined 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 classification 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 Efficient 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 epistemologi-
cal (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 andcan express almost all mathematical formalizations. It can capture rules, axioms, transfor-mation rules etc. However, they are seldom readable or comprehensible to the commonhumans, 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 adata structure, used for knowledge representation, much similar to the fragmentary theoryrole 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 featuresof the object of interest. Current W3C standard for ontology, OWL is one such frame basedlanguage. 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 knowl-
edge 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.
v 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 evolu-
tion 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 cri-
teria for ontology as put forward by Gruber. Moving on, we describe some ontol-
ogy 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 his-
tory and background of ontology has been carried out by Chira (2003). Chira has
clarified that researchers while developing ontologies employ ontology-based mean-
ings 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 stor-
age 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 knowl-
edge 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 representa-
tions 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 dis-
course,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 conceptual-
ization.”
Studer, Benjamins & Fensel (1998) has combined both Gruber and Borst’s defini-
tion as:
“Ontologies are explicit formal specification of a shared conceptualiza-
tion.”
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 lan-
guage.
• 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 hav-
ing 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 in-
cludes definitions and an indication of how concepts are inter-related which
collectively impose a structure on the domain and constrain the possible in-
terpretations 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 definition 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 definition
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
definition of ontology to be as:
R An ontology is an explicit formal conceptualization of a shared un-
derstanding 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 on-
tology (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 tar-
geted 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, docu-
ment 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 interoperabil-
ity 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 re-
quires a set of methodologies in addition to the central ontology. Query and
search facilities like that of Xpath, Xquery, SparQL and RACER enable interoper-
ability between like-minded ontologies.
• Interoperability at Knowledge Level: Interoperability at knowledge level re-
quires 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
specificity 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 rel-
evant 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 on-
tology. 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 Architecture2 The DoD Architecture Framework, Department of Defence, USA, DoD Architecture Frame-
work Version 1.0, volume 1. Definitions and Guidelines. 9 February 2004. Available on-line at http://www.defenselink.mil/nii/doc/DoDAF_v1_Volume_I.pdf Last accessedon 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 possi-
ble 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 indepen-
dent 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 artifactwhen 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 on-
tology, 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 sepa-
rate 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 fill in the details of a preferred existence
domain as a contribution to applied scientific 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 ontol-
ogy, descriptive and formalized ontologies. He discusses the role of Logic in these
formalisms of ontology. While some philosophers have subscribed to the distinc-
tion between ontology, logic and computation models, Husserl’s Logical Investiga-
tions (1970), incorporates logic to be an essential part of formal ontology. This the-
ory 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 ax-
iomatic relationships between the concepts. It is still unclear as how the distinc-
tion 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 ap-
proach to NL (Natural Language Processing) which uses an ontology as a central
resource for extracting and representing meaning of natural language texts, reason-
ing 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 conceptualiza-
tions 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 applica-
tion which is similar to the purpose definition of ontology as recommended by re-
searchers like Gruninger (1995), or Noy and Hafner (Fall 1997). Nirenburg and
Raskin propose that formal ontology can help to decide how to organize the con-
cepts 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, pro-
cesses, 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 for-
mulated 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 influence 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 infer-
ence over symbolic representations of discourse meanings and knowledge of
syntactic, morphological and phonological/graphological properties of par-
ticular languages.”
3.3.3 From Knowledge Management to Information Systems
Another relevant theory that has profoundly influenced 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 defines
‘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 mean-
ing 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, five 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 define 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 rela-
tionships 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 sci-
ence 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 on-
tology 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 sev-
eral 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 pro-
posal 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 sup-
ported 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 di-
rected 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 re-
lated 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 surround-
ings (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 on-
tology. 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 expe-
riences of the ontology engineers refine the initial setup till no further clarifications
can be achieved. Hypothetically, this implies that the set of ontology concepts de-
duced 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 cap-
ture 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, conceptual-
izations 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 classified ontologies depending upon their
formality and complexity as a continuum as belonging to the following major cate-
gories:
1. Highly Informal: Ontologies that are expressed loosely in natural language.
2. Semi- Informal: Ontologies expressed in a restricted and structure form of nat-
ural 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 classification 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 depen-
dence 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 influ-
enced 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 partic-
ular 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-
cific 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 artificial intelligence purposes that have now been widely accepted. We
briefly quote his proposed criteria below, which are self explanatory in their simplic-
ity:
• Clarity: Ontology should be able to effectively communicate its intended mean-
ing to its users.
• Coherence: Ontology should support inferences that are consistent with its def-
initions.
• Extendibility: Ontology should be designed to anticipate the uses of shared vo-
cabulary. One should be able to define new terms based on the existing defini-
tions.
• 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 define
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 reflect 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 method-
ologies 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 first 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 effec-
tively, 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 figure 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 difficult 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
first 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 strat-
egy 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 in-
tended 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 termi-
nology 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 /concep-
tualization captured in the previous phase using some chosen formal lan-
guage. 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 mo-
tivate 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 require-
ments that are represented as questions. The ontology must be able to represent
these questions using its terminology and characterize its answers using the ax-
ioms 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 on-
tology 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 ‘cod-
ing’ 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 com-
pleteness theorems that define the conditions under which solutions to the com-
petency 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 first 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 Protege 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 build-
ing ontologies. They advocate an iterative and refinement process and have pro-
posed 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 alter-
natives.”
2. “Ontology development is an iterative process.”
3. “Concepts in the ontology should be close to objects (physical or logical) and re-
lationships 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 Protege 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 compe-
tency 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 com-
mitted to some specific application or may be coded in some other knowledge
representation form. They suggest the use of other similar ontologies in Protege
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 ap-
proach 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 con-
cepts. 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 deci-
sion 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 individ-
uals (instances).
As we see, Noy and McGuinness method is simple, explicit to follow for an in-
formation system designer. The only disadvantages are that it is not implementation
tool independent. Also conceptual model assumptions are implicit in the implemen-
tation. Protege is a user friendly environment, but still the ontology is not readily
communicable to non- Protege users or non-ontology experts.
4 Protege is an open source ontology editor and knowledge base framework maintained byStanford University. Currently it is 20 years old and has a growing user community of over75000. 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 unified 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 workflow, analysis workflow,
capturing and modeling phase etc in (De Nicola & Missikoff 2005).
3.8.5 METHONTOLOGY
The final 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 method-
ologies are not explicit on how the ontology can be further modified 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 Specification: Just as one never starts a trip without knowing the des-
tination 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 tech-
nique as also proposed by Gomez -Perez et al (1996). We describe their concep-
tualization method shortly.
• Phase 5: Formalize: The next step recommended can be quoted as “To trans-
form 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-
Perez 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 depen-
dencies 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-Perez, 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 documenta-
tion is vital as in any software development project, not only for easy reusability,
modification, but also for configuration 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-Perez & 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 first 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, con-
cepts, 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-
Perez, 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 def-
initions, meanings, attributes, instances etc; a table of instance attributes should
provide information about the attributes and its values; tables of class attributesto 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 exe-
cuted and so on.
• Similarly the set of verb diagrams include a verb dictionary- to express the mean-
ings 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 design-
ers 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 itscontents 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.
v 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 epistemo-
logical 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 rep-
resentation 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 ontol-
ogy 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 explana-
tory 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 quan-
titative relationships between them. Models in this sense are constructed
to enable reasoning within an idealized logical framework about these pro-
cesses 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 first
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 abstrac-
tion 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-specific thought that is
common to specific 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 an-
other 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 reflect 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 be-
tween incompatible type systems in databases and Object-oriented programming
1 Immanuel Kant’s original work Logik was published in 1800, the current excerpt is fromthe 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 model-
ing. 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 formal-
ization 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 repre-
sentation and is also a type of conceptual data model. The first phase of in-
formation system design, that is requirement analysis uses ERM to describe in-
formation 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 rep-
resentation 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 first 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 de-sign 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 represen-
tation
• As a set of conceptual modeling patterns for application engineering from natural
language to ontology
Chen identifies four levels or views of a data model (figure 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 model-
ing for the design and development of ontologies we shall restrict ourselves to the
discussion of the first two steps mentioned above.
72 4 Conceptual Modeling
Fig. 4.1. Human Knowledge from Different Perspectives
Chen defines:
• Entity: Entity is a thing that can be distinctly identified.
• 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 relation-
ships 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 defined 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 re-
garding 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 orga-
nize and model knowledge in ontologies.
2. The relationships in the ER model, are by definition functional relationships
which associate objects. In ontology, we have more complex relationships which
may again be concepts in themselves. As defined 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 struc-
tures 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 specification. 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 seman-
tic networks (Brachman 1977), conceptual dependency graphs (Schank 1975) and
knowledge graphs (Hoede & Willems 1989). Conceptual graphs as a knowledge rep-
resentation 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 identifiable advantages:
1. Supporting direct mapping to relational databases.
2. Providing semantic basis for natural language.
3. Supporting automatic inferencing to compute relationships not explicitly men-
tioned.
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 to-
wards 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 us-
age 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 sortlabel.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 be-
tween 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-
sified 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 relation-
ships 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 relation-
ships between concepts. The concepts are independent of the domain of application.
Bunge defines the intension of a concept as “possibly infinite 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 fea-
tures. 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 definitions 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, tax-
onomy (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 nota-
tions.
• 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 com-
prehend 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 efficiency) 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 re-
moved 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, verification, 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 lan-
guages rather than the principle of conceptual modeling itself. Jarrar & Meersman
(2002) point out aptly that conceptual models are typically intended for use dur-
ing 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, first a conceptual markup language based on ORM
(ORM-ML) and for the second, they propose DogmaModeler as an ontology engi-
neering 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 inter-
action problem, which influences 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 advan-
tageous. 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 beneficial: 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 devel-
opment 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 sim-
ilarity between conceptual modeling and ontology modeling. Conceptual modeling
is appropriate for ontology design. However, to build a consistent and clear concep-
tual 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 find ontology designing easier ifthey are provided with a comprehensive methodology consisting of design anddevelopment guidelines, recommendations as well as set of conceptual modelingand analysis patterns.
In software engineering, we are familiar with the use of patterns. Patterns sup-
port 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 pat-
terns 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 first 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 classified design patterns in to two categories:
• Conceptual modeling patterns: A conceptual modeling pattern is aimed at rep-
resenting 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 tem-
plate for the design patterns as:
Pattern Name: A name for accessing and identifying the defined 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 specified 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-
sification 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 ad-
dition, experiences and best practices for the patterns are stored in a knowl-
edge 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 specification pattern consists of an application independent model of a
domain structure,.......a specification 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 specific domain patterns like the adoption of the ECA rule analysis specific to our
military case study domain.
We also follow a template like pattern for describing our O4IS design methodol-
ogy 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 model-
ing.
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, own-
ership, 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, organiza-
tions 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 ne-
cessitates that we are able to capture and represent the dynamical aspects of a do-
main 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 ad-
vantages 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 Specification. 2003. www.omg.org/cgi-bin/doc?ptc/2003-08-02
82 4 Conceptual Modeling
Event Characteristics: The characteristics of an event are defined by Olive as
the set of relationships in which the event participates.
Event Constraints: Describe constraints and conditions that an event must sat-
isfy 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 concep-
tual 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 model-
ing 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 usu-
ally 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 briefly 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) dia-
grams 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 derGrundlage ”Ereignisgesteuerter Prozeketten (EPK)” (Rep. No. 89). Saarbrcken: Universittdes 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 flow 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 dia-
grams used to represent the procedural flow aspects of an enterprise. The struc-
tural diagrams that include the UML class diagram, component and deployment
diagrams are used for modeling the static aspects of a system. Behavioral di-
agrams 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 dia-
grams 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 in-
troduced 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 stan-
dardized 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 tar-
geted 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 flow 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
figure 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 ex-
tensional 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 unified semantic procedural pragmatic con-
ceptual 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 first 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, his-
tory 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 meth-
ods.
v 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 philos-
ophy, 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 enter-
prise and business process ontologies model static concepts, i.e. endurants. Dynamic
concepts, i.e. perdurants, such as change or process, need also to be conceptual-
ized 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 as-
pects 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 chap-
ter 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 as-
pects 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 op-
tions available for conceptual modeling of process and behavior in section 4.6. One
such language for knowledge representation, Unified 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 dia-
grams 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 specific design choices an Information Systems(IS) de-
signer 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 on-
tology?
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 pur-
poses?
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 repeata-
bility 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 require-
ments influence 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 pro-
ceed 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 sufficient 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 de-
scribes, 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 to-
gether all the other above-mentioned constructs, methods and models that are pro-
posed 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 figure 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 conceptualiza-
tion 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 sim-
plicity 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 effi-
cient in introducing the world of ontology building to a novice, specially if the IS
designer is using the Protege 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 applica-
tion needs.
• Design methodology should be comprehensive and should be able to capture se-
mantics, 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 identified 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 hu-
man users as well as processable by machines capable of supporting inferencing.
• Domain conceptualization should be free of any encoding bias, including knowl-
edge 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: flexibility; reusability; easy maintenance; rapid
development life cycle; extensibility; traceability; machine readability; support evo-
lution 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 develop-
ment.
As seen in figure 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 representa-
tions 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 de-
scribe 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 partic-
ular 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 identified 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 figure 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 identified scope of the ontology and its application context, the peo-
ple 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 ex-
pertise 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 en-
trepreneur like the vehicles and their leasing prices. The targeted users of an ontol-
ogy 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 dis-
tributed 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 on-
tology 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.html2 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 identified the scope, and know the basic architecture and develop-
ment 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 un-
derstanding and communication, then a complex formal knowledge representation
is not warranted.
Input: Uschold & Gruninger (1996) have classified 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 illus-
trated 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 repre-
sentations using Web Ontology Language (OWL).
R This Dual Conceptual Representation of the domain, is a novel ap-
proach 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 implementa-
tion, the designer should always analyze and represent the domain knowledge as
conceptual models first and thereafter implement these conceptual models as for-
mal 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 cap-
turing the domain first in natural language. Or the designer may choose the sto-
ryboard 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 mat-
ter experts, that is the domain experts, the targeted users etc. As a part of our pro-
posed Unified Semantic Procedural and Pragmatic Design for conceptualization of
domain knowledge, we also propose a set of conceptual analysis models for ana-
lyzing 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 Protege Ontology Editor as our ontology design and de-
velopment 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 knowl-
edge retrieved. Here, we propose that the designer makes use of our Unified 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 for-
malisms). 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 fun-
damental 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 method-
ology 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 subse-
quent 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 identified 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 finally implements the conceptual models as formal on-
tology.
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 Protege 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 Protege ontology editor, insert all the concepts, their characteris-
tics, 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 re-
quired.
Procedure: We choose the competency questions phase as suggested by Gruninger
and Fox (1995), for assessing the minimum level of required information to be cap-
tured and modeled to support the level of inferencing and targeted application us-
age. Also, they help in tracking and authenticating the source and interpreted infor-
mation 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 ab-
straction 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 pack-
ages 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 de-
signed 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 intro-
duced, 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 on-
tology 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 Protege, 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 sec-
tion 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 on-
tology or hybrid ontology design architectures for the physical architectural organi-
zation 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 pro-
posed 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 appli-
cation 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 wouldwant 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. We3 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 Specific 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 devel-
opment 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, specific domain
ontology and the application or template domain ontology as seen in figure 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 tar-
geted 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 spe-
cialization 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 sim-
ilar 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 ontol-
ogy, we enhance reusability. Specific applications having specific needs and spe-
cializations will be restricted to the lower most ‘template’ or application ontol-
ogy. 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 Ontology5 Bunge Wand Weber
108 5 Ontology for Information Systems Design Methodology
3 Easy to modify, update, de-bug and maintain: A modular design and devel-
opment 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 tem-
plates 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 recom-
mend 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, in-
teroperability 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 trans-
form 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 lan-
guage.
We discuss more on the specific suitability of UML as conceptual modeling lan-
guage 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 expla-
nations, 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 for-
mal 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 con-
ceptual 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 sec-
tion 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 con-
ceptual 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 captur-
ing the meanings rather than representing knowledge in syntax and specifications.
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
Cranefield & Purvis (1999) and Baclawski et al (2001) as:
• It has a growing user audience in the software domain for object-modeling lan-
guages 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 com-
munication between humans for software design purposes.
• UML can be extended to suit the need of ontology definitions.
• Object Constraint Language allows expression of rules and constraints. Crane-
field (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 di-
agrams 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 Definition Metamodel) (2006) ef-
forts, 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 as-
pects as well. We have proposed a set of conceptual models for specific be-
havioral, 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 specifications like
RDFS 7, and DAML 8. The UML conceptual models may also form the base for rigidly
formal ontology definition 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
specification. http://www.daml.org/
v 6
Unified Semantic Procedural Pragmatic Design
Most enterprise and business process ontologies model static concepts, i.e. en-
durants. 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 advo-
cate 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 method-
ologies 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 con-
cept, 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 sce-
nario:
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: cus-tomer, fast food restaurant, salesperson, food, money, order, menu. But we also see
that there are more business activity-oriented concepts like, the customer places or-der, salesperson issues bill, customer pays bill, salesperson delivers food, customer eatsfood. 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 processconcepts and currently defines over 5000 business activities. It can be browsed online athttp://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 hisfood 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 ismore 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 Unified 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 methodol-
ogy 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 knowl-
edge 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 se-
mantic 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 the2 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 stan-dard 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 flow diagrams, event process
chains, UML activity diagrams) or process modeling languages, as also briefly re-
viewed 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 mod-
eling 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 Unified 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 busi-
ness 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, specifically 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 ap-
proach, Unified 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 busi-ness vocabulary, business facts, and business rules; as well as an XMI schema for the in-terchange of business vocabularies and business rules among organizations and betweensoftware tools.
4 W3C recommended Web Ontology Language for Services. Consists of a set of ontologies in-cluding Service Ontology, Process Ontology, Profile Ontology, Grounding Ontology, LogicalExpression 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, con-
straints), 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 descrip-
tions. The goals of natural language understanding and semantic conceptualizations
of domain knowledge representations, as investigated by Sukkarieh (2001), are sim-
ilar to those of ontology design goals and objectives in Information Systems as men-
tioned 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. Unified Semantic Procedural Pragmatic Perspectives
118 6 Unified 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 figure 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 inten-
tions, 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 pat-
terns 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 mean-
ing (semantics), their intentions (pragmatics) and plan of action (procedural knowl-
edge). 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 nat-
ural language (lexical structures) in precise, unambiguous, and easy to understand
conceptualizations. The final 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 specific 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: Classification Levels
• Fundamental categories: These represent the natural division that can be seen
in the real world. There are three basic types of fundamental categories: sta-
tus, 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 <is-owner-of> 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 <becomes
-owner-of> B. (this is particularly relevant for us since we wish to identify dy-
namic 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 <sends- message-to> 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 re-
lationship. Interactions are used to describe notable effects or results of some rela-
tionship 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 analy-
sis 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 five fundamental
categories, namely, assertives, commisives, directives, declaratives and expressives.
Vanderveken has carried out a semantic analysis of about 200 odd English perfor-
mative verbs, and we have based our performative verb ontology primarily on his
work.
The basic semantic pattern is of the type Actor <Performative Verb Primitive
> Actor, The Entity 1 actor is termed as ‘Speaker’ or ‘Performer’,and the entity2 ac-
tor 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 con-
textual 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 contex-
tual 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 ExampleAssertive The seller notifies the buyer that his ship-
ment 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
file 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 them-
selves. 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 specifi-
cally indicated. The implicit nature of the contract clause given above may be inter-
preted 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 se-
mantic analysis of English performative verbs. Vanderveken sets out to understand
the correspondence and distinctions of the speech act verbs with their performa-
tive 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 <speech act
verb> Hearer. Vanderveken aims to understand the paradigmatic central illocution-
ary 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) classifi-
cation 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 classification:
• 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 performa-
tive use. We have compiled his work as an ontology using Prot’ege ontology edi-
tor. 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 de-
fined 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 Protege.
Fig.
6.7.
Perf
orm
ativ
eVe
rbO
ntol
ogy
126 6 Unified Semantic Procedural Pragmatic Design
6.5 Semantic Analysis Representations: Discovering SemanticRelationships
In this section, we now present the set of semantic analysis patterns for relation-
ship 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 concep-
tual 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 definition) that define the taxonomi-
cal, or physical or constructive relationship.
• Functional Relationships: Relationships that semantically describe the func-
tional associations like cause-effect relationships.
• Temporal Relationships: Relationships between actions that describe the tem-
poral 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 ex-
tends 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 ap-
propriate 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 help-
ful 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 <entity1 -verb- entity2> 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 > Body2 Object Attribute is-part-of Car < has > Color3 Object Object is-instance-of Video Tape < is-a-copy-of >
Movie4 Attribute Attribute is-instance-of Red < is-instance-of > Color5 Actor Actor is-member-of Player < is-member-of > Ice
Hockey Team6 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 re-
lated 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 Unified Semantic Procedural Pragmatic Design
Table 6.3. Functional Relationship Patterns
No. Entity1 Entity2 Valid Primitives Example
Interaction CategorySub Category: Not Causing Change1 Actor Object View Status Analyst <analyses> Requirements2 Actor Object Select Customer<selects> Car3 Actor Actor Communicate Buyer<talks-to> Seller4 Object Object Communicate Modem < negotiates-with> Telephone Line5 Actor Object Perform Buyer <accepts> GoodsSub Category: Performance6 Actor Action Perform Buyer< does> Buying7 Actor Object Operates Pilot <flies> Aircraft8 Actor Actor Serve Salesperson < serves > CustomerSub Category:Causing Change9 Actor Object Manipulate Examiner <grades> Exams10 Actor Object Transmit Bank <remits> Money11 Actor Object Receive Buyer <receives> ShipmentStatus CategorySubcategory: Temporal12 Action Action Follow/Precede Car Rental <follows> Car Booking13 Action Action Requires Construction <requires> ApprovalSubcategory: Spatial14 Object Object is-next-to Finland < is-neighbor-to > Sweden
Table 6.4. Action-Action Functional Relationships
Action1-Relationship-Action2
Explanation
is a sub action of action 2 is carried out as a sub task of action 1in order that action 1 is to be done in order that action 2 may be per-
formedis an alternative to Action1 may substitute action2in response that action 1 is carried out in response to action 2is a prerequisite for action1 must be completed as planned before the com-
mencement of action 2is a template for action 1 is an example for action2 to conform to.is the cause for action 1 is the cause for action 2uses 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
(c) A starts and ends after B (d) A ends after B
(e) A starts and ends beforeB
(f) B starts and ends before A
(g) A starts after Bstarts and ends when Bends
(h) A starts after B starts andends when B ends
(i) A starts when B startsand ends after B ends
(j) A starts when Bstarts and ends be-fore B ends
(k) A starts before B starts andends after B ends
(l) A starts after B starts andends before B ends
(m) A starts whenB starts and endswhen B ends
(n) A starts before B startsand ends before 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 (nostatement about endings)
(b) A starts after B starts (nostatement about endings)
(c) A starts before B ends (nostatement about A ending or Bstarting)
(d) A ends after B starts (no state-ment about A starting or B ending)
(e) A ends before B ends (no state-ment about starting)
(f) A ends after B ends(no statement aboutstarting)
(g) A ends before B starts (nostatement about A starting or Bending)
(h) A starts after B ends (nothing aboutA ending or B starting)
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 abstrac-
tions – 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 actual-
ity. 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 us-
ing 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 de-
ontic 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 in-
dicates the nature of the proposition being made. The exhaustive lists of basic De-
ontic Assertions are Obligation, Permission, Prohibition and Rights. Other as-
sertions like request, desire, and guarantee may all be subsumed in to these basic
Deontic Assertions. Deontic Propositions have a core meaning which is usually rep-
resented by a verb that is the act, for example, to pay, to send, to receive, and to ac-
knowledge. 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 Protege 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 af-
fairs 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
-
Fig.
6.10
.Deo
ntic
Ana
lysi
sM
odel
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 deon-
tic 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 no-
tion 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 classification 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 fulfilled 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 af-
fairs. In figure 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 Unified 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 con-
dition 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
.Bas
icD
eont
icPr
opos
itio
n
138 6 Unified Semantic Procedural Pragmatic Design
-
Fig.6.12.Nested
Deontic
Proposition
6.5 Semantic Analysis Representations: Discovering Semantic Relationships 139
-
Fig.
6.13
.Con
diti
onal
Deo
ntic
Prop
osit
ion
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 appli-
cations is widely accepted. As with any other application, the need for supporting
constraints, policies, rules is self evident. Event-Condition-Action rules are an in-
tuitive 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 in-
cidents. 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 pre-
scribed action is allowed. Action in the ECA rule ontology indicates not only phys-
ical 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 im-
plicit 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 re-
lationships 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 ac-
tion 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 ontol-
ogy 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-
Fig.
6.14
.EC
AR
ule
Ont
olog
y
142 6 Unified Semantic Procedural Pragmatic Design
-
Fig.6.15.ECA
Rule
Ontology:A
nIllustrative
Example
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 five 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 ear-
lier, the semantic vocabulary forms a fundamental component of ontology. Thus the
identification 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 Unified 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 analy-
sis; (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 ontolo-
gies, 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 pat-
tern 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 in-
cluded.
Output: Describes the expected output or end result of this step.
Step 1 Identify the key concepts within the identified domain.
Input: Our identified 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 charac-
teristics 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 identified 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 Unified Semantic Procedural Pragmatic Design
The next task is to build a lattice of concepts, where each layer on top is a gen-
eralization 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 define our
domain. For example, for our domain of a car rental company, we begin by iden-
tifying 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
specific characteristics for each individual. Thereafter, following the ER conceptual-
ization 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 charac-
teristics ‘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 ap-
proaches. 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 suffi-
cient 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 re-
ports, 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 (in-
troduced below in table 6.2).
Procedure: In the previous step, we have listed and identified the concepts per-
taining to the domain of interest. Now, we build the network of relationships be-
tween 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 associa-
tion 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 prop-
erties 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 cate-
gories 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 model-
ing 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 relation-
ship 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 asso-
ciate 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 per-
spective is not identical with the same concept as represented by the entity rela-
tionship 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 ontol-
ogy 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 figure 6.17. We have modeled
the relationship between MyCar and the car body type sedan as an instance-of
structural relationship.
150 6 Unified 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 figure 6.18, we have identified some characteristics of Sedan, SUV(Sports Util-
ity Vehicle) and Minivan, which could answer our competency questions. Some ad-
ditional 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 five door Combi body.
• An SUV can seat either five 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 be-
tween concepts. In the figure 6.19 we have now modeled the seating capacity and
steering control as ‘properties’ of the car body. Since, we have inheritance of proper-
ties, 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 Unified Semantic Procedural Pragmatic Design
Fig. 6.19. Adding Semantic Relations
Output: At the end of this step, we should have iteratively discovered more con-
cepts as sub concepts or related concepts. We first have the hierarchical (structural)
taxonomy and that ‘grows’ as we add more and more related concepts. At the fi-
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 Define 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 identified and formed the structural hierarchy of con-
cepts, 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 de-
fined 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 char-
acteristics 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 Define 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 devel-
opment environment like Protege.
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 dis-
cussed so far. For this research, we use Protege 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 Protege Ontology editor
from CODIP project and the Noy and McGuinness guidelines.
Protege 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 Protege 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 lin-
guistic 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 on-
tology 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 Protege.
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. Define the Individuals.
Input: Ontology implemented in chosen ontology editor, documented list of iden-
tified 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 Protege 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 Protege Ontology Editor
R We propose that all concepts that we initially discovered to have the
structural relationship as instance-of in the first step, should be modeled as individ-
uals.
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 relation-
ships 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) char-
acteristics 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 be-
tween 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 stereo-
typed 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 doaction 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 an-
other 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 ac-
tion 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 Unified 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 betweenentity-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 identi-
fication 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 pay-
ment’, 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 identified 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 modified with entity-action-object functional relationships.
Step 3:Identify Action-Action Functional relationship.
Input: The modified SCV from previous step, Functional action-action relation-
ship patterns (table 6.4).
160 6 Unified 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 seman-
tically to each other. For example, an action A can occur because action B has hap-
pened 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 rela-
tionships 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 re-
lations. ECA rule ontology for prescriptive relationships.
Procedure: Similar to the previous two steps, in this step we discover the depen-
dencies 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 Workflow Methodology to deduce
such procedural views from the Semantic conceptual models in section 7.12.3. We
shall also suggested workflow 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 anal-
ysis 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, de-
ontic, 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 eas-
ily 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. Specifically, we are interested in the analyzing the
deontic modalities of the domain and its subsequent implications on the semantics.
162 6 Unified 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 specific applications for a specific purpose. The conceptu-
alizations 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 ExampleA wants to be B intent Customer<wants to own> ProductA attempts to becomeowner of B
attempt Customer <orders> Product
A becomes B transition Customer <receives> ProductStatus Primitive: Customer <owns> ProductA dislikes being B intent Customer <wants to sell> ProductA attempts to give up B attempt Customer <offers> ProductA gives up ownership ofB
transition Customer <sells> Product
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 rela-
tionship, for example, the implicit meaning behind Actor <shall perform> action,
Actor <must perform> action, Actor <could perform> 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 obli-
gations 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 <communicates/intents> 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 Unified 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: Identified 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 follow-
ing 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-
tified 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, tempo-
ral, functional, deontic and prescriptive relations; (ii) Overview and design rationale
for the USP2 Design; (iii) Detailed design guidelines for the Information Systems de-
signer 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.
v 7
Case Study I: The Business Contract Knowledge
Management Project
In the previous chapters we introduced our design methodology for building ontolo-
gies. Now, we move on to the next topic of interest in this thesis, namely how do wedevelop 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 pro-
cesses, exception handling, and performance monitoring, etc. The rest of this chap-
ter 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 intro-
duce 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 technol-
ogy, 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 appli-
cation domain is in the realm of legal business contracts. Open, available contract
knowledge should help the business entities in understanding their contractual obli-
gations and their expected fulfilment business behavior.
Business legal contracts are testaments to the business trade relationship estab-
lished. 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 contrac-
tual 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 con-
tractual 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 hu-
man 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
field 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 elec-
tronic 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 implica-
tions 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 sufficient 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 search-
able source of information, could be one such approach for contract information
management.
In this case study, we propose a methodology for contract information model-
ing, representation and interpretation using an approach that is a combination of
the document centric, process centric approach methodologies and the legal cen-
tric 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 re-
lated 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 first 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 TradeAnd 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 lo-
cal regulations. Within the framework of Information Systems, this implies a need for
a translation from technical legalese in to more human or business oriented trans-
lation 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 classification system
for public procurement aimed at standardizing the references used by contracting au-thorities and entities to describe the subject of procurement contracts. established bythe 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 KnowledgeManagement
Contract knowledge management is a crucial issue in the enterprise management
perspective. However, the various approaches deal with the contract in one or more
defined perspectives. An integrated, coherent approach for contract knowledge man-
agement is needed. Specifically, legal contract knowledge is isolated from business
process knowledge in current information system approaches. Shared common un-
derstanding 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 re-
quirements. 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 pro-
cesses. Thus contracts need to be monitored and at the same time they should
govern the design of the actual business workflow.
3 A third problem is that these contracts are seldom aligned with the internal pro-
cesses and the way each enterprise actually executes these promised contracts.
4 Another problem is that with business contracts, there are always some associ-
ated 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 identified in section 7.2 through the fol-
lowing objectives:
• To foster reusable shared contract understanding: A contract knowledge mod-
eling 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 under-
standing as the primary users. The same should also be machine-understandable
and searchable to promote automated processes like contract monitoring, per-
formance monitoring, and contract drafting, etc.
- A Multi Tier Contract Ontology framework is proposed to capture the con-
ceptual models of various contracts followed by their translations to machine
understandable formats. This MTCO framework follows the multi-tier archi-
tecture 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 fol-
low 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 work-
flow 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 re-
search, 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 obli-
gation 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 fields 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 analy-
sis, 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 efficiently. In this context this research has adopted
proposed theories from other related research works in the field of knowledge man-
agement.
Workflow 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 busi-
ness 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 estab-
lishments 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 fig-
ure 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 compo-
nent 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 pro-
posed 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 objec-
tive 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 deduc-
tion 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 in-
volved 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 for-
mal 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 impli-
cations. However, we find that he has not considered the business domain aspect of a
legal contract. The relationship between an obligation and its corresponding perfor-
mance 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 the-
ories 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 moni-
toring 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 con-
tracts 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 identified the main issues for contract performance moni-
toring 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 busi-
ness 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 frame-
work for representing normative representations specially in the banking sector.
Weirenga and Meyer (1993) have provided a concise survey and review of deon-
tic logic based applications in computer science. Amongst them, Jones and Ser-
got (1992b) have proposed that at the appropriate level of abstractions – law, com-
puter systems and other organizational structure may be viewed as instances of nor-
mative 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 represen-
tation, 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 busi-
ness language for information system. Grosof (1999) has proposed Courteous Logic
Programs as a declarative approach to model the business rules and policies as ex-
pressed 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 bind-
ing 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 specifi-
cation 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 con-
tract 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 inte-
gration 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 con-
tracts 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 per-
formance.
As stated earlier, we hold the view that such rigid enforcement agents cannot sim-
ulate 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 Workflow 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 con-
tracts 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 addi-
tional input output events in a workflow.
We see that Karlapalam has adopted a document centric analysis of a contract
and mapped them to workflow approach methodology. The proposed methodology
180 7 Case Study I: The Business Contract Knowledge Management Project
for CWM has been based on above-mentioned workflow-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 identification of the following roles
of the contractual provisions:
1 Contracts define 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 de-
livery date.
4 The contracts contain formulae that are used to calculate various parameters, for
example, the cost adjustments to price or quantity depending upon fluctuation
of currency, changing duties, and tax.
We support and uphold a definition of a business contract as:
R A contract is an organized collection of concepts, obligations, per-missions, entitlements, etc. A contract has also been viewed as a collection ofprotocols that specify its operational aspects (how the business exchange is to becarried out in reality) or simply parameters (the parties, product, price, deliveryquantity, delivery date).
Our proposed MTCO is a combination of all the above mentioned aspects. A lay-
ered 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 dis-
cussion 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 ap-
proaches 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 workflows, monitoring the fulfillment 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 pro-
posed 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 enter-
prise 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 de-
cisions 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 consis-
tent. 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 archi-
tecture 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 dis-
tributed 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 ap-
proach. We begin our study and analysis from specific contract models and there-
after, 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 formaliza-
tions.
• 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 suf-
ficient 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 in-
volved in a contract execution. This is similar to modeling a dialog between two
actors, whose responses can be expected but not predicted. Therefore, we pro-
pose 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 repre-
sented using EPC diagrams as well as BPMN. We have further proposed CWM-
BPMN patterns to ease the analysis and design part for information system de-
signers.
• G9: Evaluate, assess and verify the domain ontology. The evaluation and as-
sessment 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 ac-
curacy of the models. However, the conceptual models being based on standard
contract documents and recommendations are correct to the best of our knowl-
edge. 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
Protege by annotation with Wordnet.
After the overview of how we have applied the proposed O4IS design methodol-
ogy 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 figure 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 con-
tracts. 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 con-
tracts, 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 special-
ize 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 Commissionon 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 execu-
tion 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 rec-
ommended 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 infor-
mation 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 spec-
ifications 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 con-
straints 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 commit-
ment.
Cars are the object or consideration of the Promise: a consideration is any mate-
rial 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 obli-gation 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 per-
formance 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 responsibil-
ities 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, ethi-
cal, 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 con-
tract 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 defini-
tions. But it emphasizes on the implicit and tacit understanding of fundamental con-
tractual 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
Fig.
7.7.
Upp
erLe
velC
ore
Con
trac
tO
ntol
ogy:
Ade
taile
dSe
man
tic
Con
cept
View
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, obli-
gation 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 assump-
tion 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 obliga-
tion 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 infor-
mative or declarative (also called as performative statements by some). Informative
statements pertain to the description of the actors, the subject of the contract, ju-
risdiction and other pertinent information. Declarative or performative statements
are statements of intentions or conditions, whose execution undergoes state trans-
formations. 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 exe-
cution 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 ex-
ecuted 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 fulfillment.
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 fulfilled. 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 defined 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 under-
standing, refer figure 7.9:
• Primary obligation: Has to be fulfilled 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 fulfilled by the counter party in response to the execu-
tion 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 acti-
vated 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 advan-
tage 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 car-
rier 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 de-
livery.
• Terminated/Cancelled: If the activation of the obligation is terminated or can-
celed 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
-
Fig.
7.11
.Bus
ines
sC
ontr
act
Obl
igat
ion
Stat
es:D
etai
l
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 moni-
toring 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
.Typ
ical
Con
trac
tO
blig
atio
nLi
feC
ycle
196 7 Case Study I: The Business Contract Knowledge Management Project
7.10 Specific Domain Level Contract Ontology
The second layer in our proposed MTCO, is a collection of contract types. The fo-
cus 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, pro-
curement, licensing. We also propose to map to other existing ontologies like prod-
uct 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 obli-
gations, rights and their fulfilments conditions and exceptions particular to that spe-
cific 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 com-
monly 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 con-
cepts 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
-
Fig.
7.13
.Ext
ract
from
Sale
ofG
oods
Con
trac
tsh
owin
gex
pand
edvi
ewfo
rB
uyer
’sO
blig
atio
nto
Pay
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 deliv-
ery. 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 com-
mitments 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 ex-
ecution 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 do-
main 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 sim-
ply 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 rec-
onciliatory 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
-
Fig.
7.14
.Ext
ract
from
aSe
ller’s
Obl
igat
ion
toD
eliv
eran
dit
sFu
llfillm
ent/
Unf
ullfi
llmen
t
200 7 Case Study I: The Business Contract Knowledge Management Project-
Fig.7.15.Obligation
toD
eliverand
Related
Rights
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 cov-
ered. 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 influence the business process management to a great ex-
tent. Contract compliance and performance monitoring have been a crucial concern
for most business managements. MTCO is visualized to contribute towards busi-
ness knowledge management, improving efficiency and performance. On a wider
horizon, the proposed ontology framework is visualized as a global network of in-
tegrated 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 exe-
cutable (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 Workflow Model: The Procedural Concept View 203
7.12 Deducing Contract Workflow Model: The ProceduralConcept View
A typical business sale contract between two different business organizations con-
tains data important to the business process transactions like delivery date or ship-
ping address or payment currency. The data put together, provide information re-
garding the procedures to be followed for delivery or payment. Information regard-
ing expected delivery procedure and the possible repercussions of deviations provide
the business enterprise with knowledge of their contractual obligations, and the ex-
pected 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 con-
tract 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 Workflow Model
Increasing use of ontological engineering in the realm of business process engineer-
ing has been supported by Deborah McGuinness (2000) who identifies 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 pro-
cess 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 method-
ology. 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 knowl-
edge 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 con-
tract. 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 partiesconcerned as deduced from the perspective of the governing business contractand 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 con-
cepts 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 infor-
mation 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 first 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 iden-
tify 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 spe-
cific 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 ma-
jor 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 nec-
essary. 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 be-
tween 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 con-
tractual 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 final Contract Workflow 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 dis-
cussed 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 dis-
cussed continuously in this research. The proposed CWM methodology holds good
irrespective of the representation language. All that is required is a mapping be-
tween the representation language syntax (notations) and the concepts identified in
the CWM.
We now take up the Event Driven Process Chain diagrams (EPC) as representa-
tion 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 Workflow Model: The Procedural Concept View 207
Phase 1: Contract Type Identification
Input: Contract Document, MTCO.
Output:Contract document, identified shared domain ontology or template ontol-
ogy.
Process:
Step 1: Go through the contract to identify the contract type, like sale of commer-
cial 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 head-
ing 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-defined form.
• If not, then the user should be able to locate the shared domain ontology specific
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 compo-
nents 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 con-
tract 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 specific 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, per-
formance, rights and other conditions.
• If no shared ontology can be found, then the user has to start from the fundamen-
tal 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 fol-
lowing 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 ad-
dress, 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 re-
quirement 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 de-
fined ‘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 specific descriptions and/or specifications 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 jurisdic-
tion 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 se-
curity, storage and other issues as discussed in the EC Directives’98 (EC Directives1998 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 busi-
ness. 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 dia-
gram.
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 identification
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 perfor-
mance 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 perfor-
mance 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 perfor-
mance 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 identi-
fied 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, prohibi-
tions and rights.
Phase 4: Obligation, Performance, and Non-Performance Inter-relationship
Identification:
Input: List of obligations, list of rights, List of prohibitions, list of related perfor-
mance 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 workflow 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 identified 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 obliga-
tion 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 flowchart 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 ac-
ceptance 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 Workflows
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 be-
tween 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 Workflow Sequencing
Input: Time Ordered list of obligation, obligation states, and the related perfor-
mance 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 ful-
filment.
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 connec-
tors. 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 fulfilment. 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, figure 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 rep-
resentation. 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 busi-
ness 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, collabora-
tion 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 par-
ties 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 pro-
posed 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 pro-
posed 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 exe-
cuted 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 de-
duced from the contract instance and the MTCO may use concepts or terms from
related ontologies like the enterprise ontology, business process management ontol-
ogy. 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 pro-
cesses 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 recom-
mended 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.ASam
pleC
ontractW
orkflowM
odelusingB
PMN
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 ac-
tivity, 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 cer-
tain 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 (trigger-
ing) 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 mes-
sage 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 obliga-
tions (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 Workflow Model: The Procedural Concept View 221
Fig. 7.20. Pattern 4 and Pattern 5: Contract Performance Event Sequences and SimultaneousProcessing
Examples: The seller makes goods at the same time he also arranges for car-
rier, and procures packaging material. The seller would wait for all the three paral-
lel 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 outflow may also be modeled using the conditionExpression
attribute of the out going sequence flow.
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
flow 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 irrespec-
tive 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 situa-
tion 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 influenced by
management policy, and legal jurisdiction etc. The scenarios should be modeled as
a complex decision, signifying human intervention.
7.12 Deducing Contract Workflow 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 specification 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 figure 7.22)
BPMN Mapping: COMPLEX Decision Gateway.
In the next section, we shall see how such contract workflows 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, inter-
operability of enterprise systems and management of contract knowledge are some
examples of how an ontology for Information Systems may be used. Thus, our sec-
ond goal of exemplifying how ontologies may be used in Information Systems is
fulfilled.
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 follow-
ing, 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 busi-
ness 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 mech-
anism 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 for-
ward 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 possi-
ble execution scenarios. Chen’s work lays the foundations for a conformance check-
ing 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 in-
dependent, since we ourselves have only exemplified using EPC diagrams and
BPMN, Chen has used Petri nets to model his contract compliant workflow mod-
els.
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 vio-
lations 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 sup-
porting 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 fine for late delivery or unsat-
isfactory delivery.
• Right To Cancel: The Buyer may cancel the specific 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 de-
scribed 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 exam-
ining 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 de-
livery 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, fulfilled)
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 specific violation and pro-
poses a solution on how that exception is to be resolved and by whom. These pat-
terns 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 con-
tracts. 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 elec-
tronic revolution the mechanism for establishing these business and trade relation-
ships 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 man-
ner. 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 ana-
lyze 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 ar-
eas 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 Identification of primary obligations. The underlying assumption for starting
here is that we regard non-fulfilment 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 de-
rived 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 methodol-ogy for model-based risk analysis of security-critical systems. The project was initiatedin January 2001 and successfully completed in September 2003. For more details referhttp://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-fulfilment. 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 ef-
fects 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 deci-
sion 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 miti-
gation 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 con-
ceptual 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 method-
ology 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 ex-
plicit 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 prob-
lems 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 fo-
cused only on the contract execution phase. The approach methodology is to be
extended to cover other phases of contracting from drafting to signing. This re-
search 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 le-
gal 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 inter-
preter 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 workflows. 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 in-
clude:
• 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 classification of contract obligation
types and the pragmatic states that each obligation passes through is unique con-
tribution. The utility of the obligation state analysis in performance monitoring,
business contract risk assessment has been put forward.
• CWM: The contract workflow 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 hu-
man interpreters who are not familiar with legal terminologies. Thirdly, to align,
plan and integrate the contract compliant process model into the internal busi-
ness 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 on-
tology 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.
v 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 refine 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 figure 8.1.
Fig. 8.1. Case Study II- Chapter Disposition
We shall begin by a description for the case study, thereafter a short back-
ground for the military modeling and simulations domain, focusing on military op-
erations(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 (sec-
tion 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 sup-
port 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 captur-
ing 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 field 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 mili-
tary 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 knowl-
edge. 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 dic-
tionary, 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 specific 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 concep-
tual 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 system-
atically 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 specific analysis,
design, and implementation.
8.1.2 DCMF Project Objectives
Thus the overall objectives for the DCMF project is to capture authorized knowl-
edge 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 substan-
tive 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 interop-
erability 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 on-
tologies 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 con-
ceptual models, which in turn are based on the proposed ontological knowledge
base. Therefore, the simulation models and the DCMF-O should be able to in-
teroperate 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 devel-
oper 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 credi-
bility, authenticity of source etc. In short, the ontology should be readily verifi-
able 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 re-
volve 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 con-
stant 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 knowl-
edge 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 re-
quirements 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 unstruc-
tured 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 arti-
cles 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 first phase, KA has two main objectives. First,
to put forward a set of requirements for the expected output, for a specific pur-
pose. 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 understand-
ing 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 se-
mantics of vocabulary as well as pragmatics. By semantics, we mean that the in-
tended 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 concep-
tual 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 model-
ing 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 ad-
vanced 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 find many practical hurdles in applying any one of them construc-
tively 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 re-
searchers from the ontology building exercise in particular domains, they have
hesitated from involving any domain specific design constraints or functional re-
quirements 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 con-
ceptualization needs that the procedural aspects or the state of affairs for plan-
ning 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 methodol-
ogy 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 flexibility, 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 method-
ologies 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,
specifically 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 scenar-
ios.
• 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 ap-
plications 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 evalu-
ated. Currently, we are supporting only manual knowledge extraction and map-
ping using our proposed Semantic Analysis Representation. But, our ongoing
work in this project also focuses on semi-automatic support for knowledge ex-
traction.
• G7: Knowledge analysis- Conceptualize the domain ontology. We conceptu-
alize 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 Protege 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 recommenda-
tions 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 method-
ology 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 architec-
ture as discussed in the O4IS earlier. The structure is as shown in figure 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 specific 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 de-
velopment 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 rep-
resentation 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 devel-
opment 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 infor-
mation 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 specification states:
• A description of the common data in the JC3IEDM that contains the relevant
data, abstracted in a well structured normalized way that unambiguously reflects
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.kif4 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 Commandand Control Information Systems (C2IS) of Canada, France, Germany, Italy, the UnitedKingdom and the United States of America in April in 1998 in Calgary, Canada. The aimof 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 inorder to support multinational (including NATO) combined and joint operations and theadvancement of digitization in the international area. The MIP solution enables C2IS toC2IS information exchange and allows users to decide what information is exchanged, towhom it flows 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 explana-
tions, 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 concep-
tual, 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, per-
sonnel, 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 com-
mand 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 neces-
sary 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 fulfil the following requirements:
1 There is a need to describe objects of military significance. 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 identified by sufficient characteristics as is required for com-
mand and control tasks.
4 There should be means to display operational status and situations as repre-
sented 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 inter-
ests 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 exam-
ple 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 im-
plement 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 rep-
resented 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, associ-
ation 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 concep-
tual 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 sec-
tions, 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 MilitaryScenarios
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 per-
formative action identified gives us the nature of the action:- if its assertive, commis-
sive, 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 con-
ceptual design pattern for capturing the prescriptive and normative behavior of
a domain. In this case study, we apply them to specific 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 asso-
ciations between <entity-verb-entity>, <entity-verb-action> or <action-verb-
action> 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 func-
tional 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 (sec-
tion 6.5.4) without the need for any further domain specific specializations.
Hence, we now only discuss the global contexts defined 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 pre-
scriptive 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 be-
havior 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.Illustrationofa
Rule
ofEngagement
analyzedusing
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 toprevent the BFOR from discharging its duties is permitted.ROE 2: The use of minimum force to defend friendly forces and personswith designated special status against hostile action is permitted.ROE 5a:The use of minimum force to prevent the taking possession of ordestruction of property with designated special status is permitted. ROE5b:Individual service personnel are to be informed when they are protect-ing specific 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 sat-
isfying since there is a loss in information and context which affects the reusability.
If too much context is lost during the process it is difficult to reuse the analyzed
information. One way of dealing with this is to fill 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 WHYA1 BFOR
LandForce
Is permitted touse minimumforce
Joint OperationsArea (JOA) inBogaland
During imple-mentation ofUNSCR’s 2377,2427, 2450 andBogaland PeaceAgreement
To prevent anyattempts by per-sons to preventthe BFOR dis-charging its du-ties
Five Ws is useful on a conceptual level to get a quick categorization and un-
derstanding 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 ActionA1 Attempts to dis-
charge of dutiesBFOR preventedfrom discharg-ing normalduty
use of minimum force
WHO Hostile forces (doesit) BFOR is affected
– BFOR does it Hostile Forces areaffected
WHAT BFOR is obstructed – Use of Minimum Force to Preventor Defend
WHEN Within peace keep-ing period
– Within peace keeping period
WHERE Bogaland – BogalandWHY Terrorism in Boga-
land– Peace keeping in Bogaland
As can be seen from the above, the information aggregated in table 8.3 has ex-
pressed 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 Protege Ontology Editor (see figure 8.10). Furthermore, we have se-
mantically 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
.EC
AR
ule
Ont
olog
yim
plem
ente
din
Prot
ege
256 8 Case Study II: The Defence Conceptual Modeling Framework Project
Fig.8.11.IllustrationofEC
AR
uleO
ntologyenriched
with
WO
RD
NET
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 identified
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 identified 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 bound-
aries 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 ExplanationOrganization Organization has assigned Organization1 has assigned re-
sources, personnel and task overto organization 2
Organization Organization has captured Organization1 has capturedforcefully organisation2
Organization Organization has detached organization 1 has a part of itselfas organization 2 separated fromthe main organization at someother location
Person Organization has full command of the military authority and re-sponsibility of a superior officerfrom within the military orga-nization who has full commandand control over given organiza-tion.
Organization Organization plays-the-role-of Organization 1 plays the role oforganization 2.
Person /Role Person /Role has operational com-mand of
the authority granted to a com-mander to assign missions ortasks to sub-ordinate comman-ders, to deploy units, to reassignforces and to retain or delegateoperational and/or tactical con-trol as may be deemed necessary.
Person /Role Person /Role has operational con-trol of
role has operational control ofthe authority delegated to a com-mander so that the commandermay accomplish specific missionsor tasks which are usually lim-ited by function, time or location;to deploy units concerned, and toretain or assign tactical control ofthese units. It does not includeauthority to assign separate em-ployment of the components ofthe units concerned.
Organization Units has attached temporary placement of units inan organization
Table 8.5. Actor/Role-verb-Action Structural Relationships
Entity1 Entity2 Relationship ExplanationOrganization action approves Organization authorizes actionOrganization action controls specified organization is in
charge of the direction, co-ordination, execution of aspecified action
Organization action Initiates starts the planning or executionof the action
Organization action is-coordinating-agent-for
organization is responsible forcoordinating the action whentwo or more resources are in-volved.
Organization action is-interested-in the specific organization takes aninterest in the specified action
Organization action is-liaison-for denotes the organization thatacts as the liaison for the speci-fied action
Organization action is-point-of-contact-for
denotes the organization that isto be contacted in connectionwith the specified action
Organization action plans the organization that performsthe detailing of the specified ac-tion
Organization action observed the organization that has wit-nessed the execution of the spec-ified action
Organization action requests the specific organization that in-dicates requests for a specific ac-tion.
260 8 Case Study II: The Defence Conceptual Modeling Framework Project
Table 8.6. Entity-verb-Entity Structural Relationships
Entity1 Entity2 Relationship ExplanationOrganization Facility administers organization is responsible for
the administration of the facilityPerson Person augments person 1 extends the capability of
person 2 in his tasks.Organization Materiel consumes organization expends the object
materielMateriel Materiel contains Ex.The bag contains the paper.Organization Facility coordinates-the-use-
ofthe organization arranges thescheduling of the facility
Person /Or-ganization/Facility
Person /Organi-zation /Facility
employs Entity1 is the the temporary orpermanent user of entity2. ex:The university employs teachers.
Person Person exploits Person 1 takes advantage of per-son 2.
Organization Person has-as-a-member ex:The student union has asmembers students
Control Fea-ture
Control Feature intersects ex: 5th Cross stress intersectswith the Highway E14.
Organization/Person
Materiel installs ex:System Administrator installsnew security software.
Facility MeteorologicalFeature
is affected by ex: Our Stockholm Headquartersis affected by hailstorms.
Person Person is-aunt-of a family relationship betweentwo persons, where person 1 is afemale, and is the sister of per-son2’s parents.
Facility /Or-ganization/person
materiel is-authorized-to indicates formal entitlement.ex:The Police are authorized touse speed cameras.
Organization/person
Organization/person
is-captor-of ex: Terrorists are captor of theBeslan 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 refined following our experiences. We are constantly analyz-
ing 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 re-
port 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 se-
quence 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 forestnear a village called Janjevo.The finding is reported in the battalion’s intelligence report and thisis tele-faxed in encrypted code to Stockholm. The information aboutthe finding is received by command central at MUST and the report isregistered in the System.The information about the found weapons is made available for thedepartment of international intelligence (MUST International Depart-ment).
Using the Semantic Concept View, we identified the main concepts ( individu-
als) 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 identified 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 inDCMF-O
Who Patrol from Swedish con-tingent KS05
Patrol: Military TypeOrganization(undergovt type object-type:Unit-Type: has Affiliationobject type relation toSwedish Contingent:Object-Item-Group.Swedish: affiliation
What Patrolling Patrolling: action-taskpurpose:WHY AOI:Location
When From 1st may to 31stMay 2002,
Reporting-Data: time
Why To secure the AOI(Areaof Interest)
Action-Objective, Con-text
Where AOI somewhere inKosovo
AOI: specification detailAOI is both a Location aswell as a CONTROL FEA-TURE: may even be a subtype of control -featurelike ROUTE etc
After the mapping, we implemented the same in our DCMF-O in Protege. 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 identified 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 do-
main, we found that with little modifications (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
.Pro
cedu
ralC
once
ptVi
ew:u
sing
CW
M
266 8 Case Study II: The Defence Conceptual Modeling Framework Project
Fig.8.14.Pragmatic
Concept
View:using
DA
M
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 BFORsoldiers as hostage. The hostage managed to escape during local fes-tivities (Lucia) when the guards were drunk. They escaped from thebuilding were they were held and was later picked up by a police pa-trol and taken to hospital. Considering the circumstances they are in agood 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 sup-port from the people on Gotland. Opposition leader Aron Aronssonis interviewed. He knows where Barkan is keeping his supplies andhostage since it is a ‘small island’. If Aronsson is assured security sup-port from BFOR he will give some information regarding Mr Barkan’swhereabouts.
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 con-
cepts, thereafter establish the functional and temporal relationships between identi-
fied 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 figure 8.17.
Fig. 8.15. Lord Barkan Hostage Scenario
8.8 Case Scenarios 269
Fig.
8.16
.Lor
dB
arka
nH
osta
geSc
enar
io:F
unct
iona
lRel
atio
ns
270 8 Case Study II: The Defence Conceptual Modeling Framework Project
Fig.8.17.LordB
arkanH
ostageScenario:Prescriptive
Behavior
Analysis
8.8 Case Scenarios 271
Fig.
8.18
.Lor
dB
arka
nH
osta
geSc
enar
io:S
cena
rio
View
er
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 perform-
ers 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 character-
istics 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 Protege implementation can be used for stor-
ing the scenario information. However, the graphical visualization facilities with the
current Protege 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 informa-
tion 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 ac-
tivity diagram only. It is possible that in future we may build support for other
formalizations like BPMN (Business Process Modeling Notation) etc. The UML ac-
tivity 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 as-
sessed 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 on-
tology 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 foun-
dations as discussed in chapter 3. The specific requirements from DCMF have been
discussed in (Kabilan, De Nicola, Missikoff & Mojtahed 2006). Since our concep-
tualizations 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 individu-
als(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 ex-
perts) 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 individu-
als in our implemented ECA Rule Ontology in the Protege 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 Protege before? If yes, how would you rate that the ECA Rule
Ontology, for analyzing ROE, has improved (on a scale 1-5), the following crite-
ria:
• 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 in-
formation 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 Protege 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 Protege.(on the account of usabil-
ity (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 first 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 appli-
cations that are underway.
v 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 first 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 method-
ologies, namely: Uschold’s Skeletal Methodology; Gruninger and Fox’s Methodol-
ogy; Methontology; Noy and McGuinness’ 101 Methodology; and UPON methodol-
ogy. 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 advan-
tages 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 briefly recap the discussion on the different proposed methodologies for cap-
turing 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 tar-
geting 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 ques-
tions.
5 From the results of the formal competency questions the specification of ax-
ioms 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: speci-
fication; conceptualization; formalization; integration; implementation; and main-
tenance. 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 tran-
sition) 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 de-
sign 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 ontol-
ogy design and development. Though, their guidelines target the ontology develop-
ment on Protege 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 identified a set of requirements that our proposed
ontology design methodology should meet. In this section we revisit those require-
ments to assess how far we have fulfilled 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 re-
quirements 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 specific 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 flexible, 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, de-
pending 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 five 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 empha-
size 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-Perez (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 knowl-
edge) 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 hid-
den 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 trans-
form the same UML conceptual model into different ontology representation lan-
guages. 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 applica-
tion, 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, verifia-
bility 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 methodolo-
gies. 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.
Tabl
e9.
1.C
ompa
riso
nof
Ont
olog
yD
evel
opm
ent
Met
hodo
logi
es
Fun
ctio
nal
Req
uir
emen
tsO
4IS
Usc
hold
and
Kin
gG
run
inge
ran
dFo
xM
ETH
ON
TO
LOG
YN
oyan
dM
cGu
inn
ess
UPO
N
Han
dle
unst
ruct
ured
info
rma-
tion
asin
put
sour
ces
SS/
NS
ND
ND
ND
S
Flex
ibili
tyan
dA
dapt
abili
tyS
ND
ND
PSN
SS
Reu
se(B
ased
on)
exis
ting
know
ledg
eba
sean
din
form
atio
nS
SS
SS
S
Inte
rope
rabi
lity
SN
DN
DN
DN
DS
Rap
idan
dea
syde
velo
pmen
tS
PSPS
SS
SFo
rmal
Rep
rese
ntat
ion
SS
SS
SS
Info
rmal
Rep
rese
ntat
ion
SS
SM
aybe
NS
SC
redi
bilit
y,A
uthe
ntic
ity
tobe
veri
fiabl
e,va
lidat
edS
ND
ND
SN
DS
Use
asa
look
upfo
ran
alys
is,
atth
esa
me
tim
eth
eon
tolo
gysh
ould
grow
SS
ND
ND
ND
S
Lege
nd:S
=Su
ppor
ted,
NS=
Not
Supp
orte
d,N
D=
Not
Des
crib
ed,P
S=Pa
rtly
Supp
orte
d.
284 9 Discussion of Results
9.3 Evaluating USP2 Design and the Semantic AnalysisRepresentations
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 sub-
stitute for some real- world concept which may be an object or some character-
istics 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 precon-
ditions and post conditions and transformations that may occur for each event
in the model. For our chosen knowledge representation both the UML concep-
tual 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 popu-
larly 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 con-
ceptual models are based on the theoretical background as discussed in chap-
ter 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 reason-
ing. To support reasoning, the knowledge representation must also describe the
behavior and interactions between the ‘things’ that make the model. Our pro-
posed USP2 Design approach fulfills this criterion. We have analyzed and put
forward different semantic relationships, namely, structural, prescriptive, tem-
poral, 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 mod-
els are translatable to machine- readable OWL. Also, by adopting the ODM rec-
ommendations, 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 knowl-
edge 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 acknowl-
edge, in the sense that we apply theory, frequently from other disciplines,
such as economics, computer science, and the social sciences, to solve prob-
lems 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-
tific 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 pro-
posed 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 instan-tiation. 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 realworld problem. The problems as we have identified are relevant and contempo-
rary. The need for faster, efficient and accurate information retrieval and pro-
cessing in Information Systems is well established. Emerging technologies like
semantic web and ontologies are supposed to resolve some of the current prob-
lems 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 sim-
ple 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 itsutility, 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 re-
search 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 knowl-
edge 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 in-novative approach to solve the problem domain. The research contributions mustbe 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 sec-
tion 9.2.3, we have presented a comparison of these surveyed ontology design
methodologies with O4IS design methodology. The scientific originality and re-
search 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 includ-
ing 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 seman-
tic and pragmatic aspects of the domain. Note that, we have focused mainly on
social domains that are inherently prescriptive or normative in behavior. Our re-
search 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 internallyconsistent. Application of rigorous methods in the design and development processmust be visible. We have endeavored to be as rigorous and transparent as possi-
ble in our design and development process. Our knowledge representation lan-
guages chosen, UML and OWL can be verified for consistency by themselves.
• Design as a Search Process: The search for an effective artifact requires that avail-able 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 knowl-
edge 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 final
chapter we recapitulate our problems, goals and our solution.
v 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 Identification and Motivation
To identify the research problem and justify its need for a solution. Problem definitionis to be used to develop an artifact as a solution. Motivation is necessary to convincethe readers to understand and accept the results that are proposed. Resources neededfor this step is a knowledge of the current state of the art, the relevance of the identifiedproblem.
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 com-
munication 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 pre-
scriptive 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 objectivesare to be based rationally on the identified problems and should lead to the developmentof 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:
• 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 Sys-
tems.
A clear and explanatory design methodology that takes care of functional require-
ments 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 meth-
ods 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 usinga theory.
Our contributions made in this thesis are illustrated in figure 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 knowl-
edge 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 flexibility, extendibility and re-usability.
• A Dual Conceptual Representation strategy for a two-step knowledge repre-
sentation 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 procedu-
ral 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 experimenta-tion, simulation, case study, proof or other means. The idea is to demonstrate howthe artifact can be used to solve the identified problem. As discussed in the previ-
ous 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 pro-
posed 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 compar-ison of the artifact to the original objectives set up. How far does the artifact fulfillthe 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 applica-
tions. 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 otherscientific researchers, practicing professionals via publications in scientific channels, andother 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 tech-
nical workshops like the Simulation Interoperability Workshop, which is a confer-
ence 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 expres-
sion 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 ad-
dressed 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 do-
main could be represented differently, interpreted differently, analyzed differently,
depending on who is doing the same, or in which context or under what circum-
stances. Therefore, the utility of a conceptualization becomes shareable and reusable
only when the context and specifics of the ontological commitment are made obvi-
ous 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 differ-
ent philosophers have different views of the world, thereby indulging in ontological
bias. If establishing consensus regarding the conceptual models would free an on-
tology 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 (sec-
tion 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 (build-
ing 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 to-
wards 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-Perez, 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 unified 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-Perez, 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-Perez, 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-Perez, 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-Perez, 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-Perez, 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-Perez, 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 quantification.Kuhn, T. (1996), The Structure of Scientific 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 Reflective 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 Artificial
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) .
v A
Appendix
In this section, we present the conceptual models for the INCOTERMS delivery pat-
terns 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 con-
tractual 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 start-
ing 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 addi-
tional 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.
(figure 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 specific
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 nor-
mally 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 des-
tination. 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 BuyerProvision of goods andComm. Invoice
Yes No
Delivery Place the goods at the namedplace of delivery on the date orwithin the period stipulated.
Take delivery as soonas they have beenplaced at his disposal.
Payment of price None Pay the price as pro-vided in the contract.
Notice to the buyer Give notice as to when and wherethe goods shall be placed at thebuyers disposal.
Not applicable
Packaging, marking Provide at his own cost packag-ing as it is required by the circum-stances relating to the mode oftransport, destination etc. Pack-aging is to be appropriatelymarked.
Providing the transportmodalities and inform-ing the seller of the re-quired packaging.
Inspection of goods None Pay the shipment in-spection and inspec-tion mandated by thecountry 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
Fig.
A.2
.Ove
rvie
wof
com
mon
feat
ures
ofth
eIN
CO
TER
MS
deliv
ery
patt
erns
314 A Appendix
Fig.A.3.IN
CO
TERM
S:Obligation
toExchange
Goods
A.1 INCOTERMS: Delivery Patterns for Sale of Goods 315
-
Fig.
A.4
.Ex
Wor
ks:A
typi
calc
ase
scen
ario
for
cont
ract
exec
utio
nbe
twee
nse
ller
and
buye
r
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 Identification
Input: The given business contract, proposed MTCO.
Step: By parsing through the contract text we should be able to judge the con-
tract 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 Identification
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 identified 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 ExtractedContract Type Sale of Goods Contract typeActor1 ABC Computers Incorporated LtdRole1 SellerAddress for Actor 1 Viderogatan 17, Kista, SwedenActor 2 Stock and Financial Movers ABAddress for Actor 2 Strandvagen 2,Stockholm, SwedenRole2 BuyerConsideration ComputersSpecification DELL PC Dimension 4550 Intel Pentium 4 proces-
sor 333 MhzContract date 12th NOV 2004Primary Obligation ofSeller
Transfer and delivery of goods
Primary Obligation ofBuyer
Receive and pay for goods.
Performance DeliveryPerformed By SellerPlace of delivery SellerDate and time SellerDelivery fulfilled when SellerPerformance PayPerformed By BuyerPlace At the place of deliveryDate and time At the time of deliveryRight to inspect Owner is Buyer.Performance Inspect goods, notify seller.Performed By BuyerTime Period Within 15 days after delivery receipt.Ownee Seller
Table A.3. Phase 3- List of Obligations
ObligationsObligation to deliverObligation to payObligation to insure the goodsObligation to accept the goodsObligation to pay penaltyObligation to package the goodsObligation to arrange for carrier for transporting the goods.
318 A Appendix
Tips: Find out who has to perform the obligation, and who is the beneficiary or
claimant for the same. Most of the standard obligation owner and ownee could be
found in the multi tier ontology, but the actual specification 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 OwneeObligation to deliver Buyer SellerObligation to pay Seller BuyerObligation to insure the goods Buyer SellerObligation to accept the good Seller BuyerObligation to pay penalty for latedelivery, delivery unsatisfactory,delivery failure
Buyer Seller
Obligation to arrange carrier fortransportation of goods (if buyeris the performer)
Buyer Seller
Obligation to arrange carrier fortransportation of goods (if selleris the performer)
Seller (performance deferred toSeller), Primary Obligation stillrests with Buyer
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 obliga-
tions in the order of their execution and their sequence within the business time
frame. Some of the identified obligations, their types and the associated obligations
as well as the identified 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 ObligationType
Nature of Obli-gation
Obligation to deliver Buyer Seller Primary Legal, businessObligation to pay Seller Buyer Primary Monetary, legalObligation to acceptthe goods
Seller Buyer Primary andSecondary
Business
Obligation to pack-age the goods
Seller Buyer Secondary Business
Obligation to paypenalty for latedelivery, delivery un-satisfactory, deliveryfailure
Buyer Seller Reconciliatory Monetary, Legal
Obligation to arrangecarrier for transporta-tion of goods (if selleris the performer)
Seller (perfor-mance deferredto Seller), Pri-mary Obligationstill rests withBuyer
Buyer Conditional(upon requestfrom Buyer)
Moral
Obligation to ar-range carrier fortransportation ofgoods (if buyer is theperformer)
Buyer Seller Secondary Business
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 iden-
tified in the previous phase, from the MTCO.
Step 2: Deduce the business activities required to execute that performance suc-
cessfully.
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 de-
liver 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 organiza-
tion (or business process manager etc). A good contract should be able to give all
required information regarding the performance events to be executed. Any ambi-
guity 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 stan-
dard 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
Obligation to Deliver
Ship goodsDeliver goods (basic performance)Load goods (extracted from internal workflow)Mark goods (from legal regulation which needsgoods to be marked for particular buyer)Get raw materials (extracted from internal work-flow)Arrange carrier (implied from contract)Quality assurance of goods (legal requirementthat goods should conform to specification)Pack goods
Obligation to package
Get information of mode of transportAssess duration of transportationAssess type of packaging requiredGet packaging materialPack goods (basic performance)
Obligation to pay
Pay for goods (basic performance)Make arrangements with bankReceive goodsInspect GoodsSend AcceptanceNotify 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 first, then the nested or secondary obligation (obli-
gations which are part of the primary obligation), followed by conditional obliga-
tions (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 obli-
gations as they could be fulfilled as a necessary sub- unit of the main primary obli-
gation 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 ObligationsObligation to deliver Obligation to payObligation to package Obligation to arrange carrierObligation To Ship Obligation to inform seller about
carrierObligation to Transfer ownership Obligation to accept goodsObligation to Remedy Right to inspect
Right to cancelRight to remedy
Step4: Separate the list of deduced activities and obligations by the performer.
Tips: Each list would ultimately lead to the business activity workflow 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 ‘can-
cel 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 param-
eters 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 EvenstsSend receipt acknowledgementfor PO
Send Purchase Order
Get Raw materials Receive acknowledgmentMake PC Cancel order (has pre condition
can occur only till ship goods hasnot occurred)
Pack PC (has pre condition:Should have received info aboutmode of transport from buyer be-fore this)
Arrange carrier
Ship PC Inform seller of carrier choiceReceive delivery receipt Receive goodsSend Invoice (has time boundedcondition Send invoice on deliv-ery receipt or after 15 days fromDelivery accepted at buyer.)
Inspect goods
Send delivery receiptReceive invoiceMake 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 de-
picted for each organization should be the recommended workflow for contract com-
pliance. The derived business workflow would probably not be complete but only an
indicative guide for recommended business process workflow as illustrated in fig-
ure 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 flows
This phase is an optional stage and can be used to map to existing internal business
process flows 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 Workflow 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 Workflow 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 Hook, 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 Scheele, 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 Mannikko-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 Unified Framework for e-Commerce Systems Development: Business Process Pat-
terns Perspective
No 04-013 Soderstrom, 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 Specifications
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 Conflicts 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 Kifle 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
