by developing tools to produce an ontology based application. ...... For the period of time when the object is a given state, the timeline runs parallel to that state.
Developing Ontology-Based Applications of Semantic Web Using UML to OWL Conversion
Moein Mehrolhassani
Submitted to the Institute of Graduate Studies and Research in partial fulfillment of the requirements for the Degree of
Master of Science In Computer Engineering
Eastern Mediterranean University July 2008 Famagusta, North Cyprus
Approval of the Institute of Graduate Studies and Research
________________________________
Prof. Dr. Elvan Yılmaz Director (a)
I certify that this thesis satisfies the requirements as a thesis for the degree of Master of Computer Engineering.
____________________________________
Assoc. Prof. Dr. Hasan KÖMÜRCÜGİL Chair, Department of Computer Engineering
We certify that we have read this thesis and that in our opinion it is fully adequate in scope and quality as a thesis for the degree of Master of Computer Engineering.
________________________________
Assoc. Prof. Dr. Atilla ELÇİ Supervisor
Examining Committee __________________________________________________________________________
1. Assoc. Prof. Dr. Atilla ELÇİ
________________________________
2. Asst. Prof. Dr. Yıltan BİTİRİM
________________________________
3. Asst. Prof. Dr. Mustafa Rıza
________________________________
ABSTRACT
UML is the standard for modeling object-oriented software for a considerable number of web services and web applications, and has been accepted by societies and system developers around the world, also so many tools support software and business modeling using UML. Semantic Web is to increase the capability of the existing web which is not something distinct from the existing one but enables people and machines to understand and work together by giving well-defined meaning to information. OWL as Web Ontology Language provides expressiveness and support inferencing, and provides advanced semantic concepts. The aim of this study is to present an approach to develop ontology-based applications for semantic web using OWL ontologies derived from UML description in order to reuse designed and developed application instead of redesigning them. All UML diagram kinds (thirteen diagrams) are analyzed and conversion rules from UML to OWL are figured out. Some diagrams had straightforward mapping to OWL and we proposed new approaches for others which had no direct mapping from UML to OWL. Conversion rules are applied to UML diagrams of an already working application as a case study in order to check the consistency and reliability of our conversion. The converted application provides same functionality to end user as the original application provides.
iii
ÖZET UML belirli sayıdaki web hizmetleri ve web uygulamaları için hazırlanan nesneye özel yazılımların modellenmesi ile ilgili olarak kullanılan bir standart olup dünya çapında ilgili dernekler ve sistem geliştiriciler tarafından kabul görmüştür. Ayrıca
birçok
araç
UML
standardını
kullanan
yazılım
ve
çalışmaları
desteklemektedir. Semantic Web mevcut olandan farklı olmayıp insanlar ve makinalara, data ve bilgilere doğru ve iyi bir şekilde tanımlanmış anlamlar vererek birbirlerini anlama ve birbirleri ile çalışma olanağını sunmakta olup mevcut web’in kapasite ve kabiliyetilerini arttırmaktadır. OWL, Web Ontoloji Dili gibi ifade ediciliği sağlayıp sonuçlandırma ve anlam çıkarmayı desteklemekte ve ileri Semantic konseptleri sağlamaktadır. Bu çalışmanın amacı, uygulamaları yeniden tasarlamak yerine tasarlanan ve geliştirilen uygulamaları tekrar kullanmak amacıyla UML tanımından türetilen OWL ontolojilerini kullanan semantic web’ler için ontoloji bazlı uygulamaları geliştirmek üzere bir yaklaşım sunmaktır. Tüm UML diyagram tipleri ( on üç diyagram ) analiz edilmiş olup UMLOWL dönüşüm kuralları elde edilmiştir. Bazı diyagramlar kolaylıkla OWL’e dönüştürülebilirdi ve bu çalışmada UML’den OWL’e doğrudan dönüşümü bulunmayan diğerleri için yeni yaklaşımlar önerilmiştir. Örnek bir çalışma olarak önerilen dönüşüm kurallarının uygunluk ve güvenilirliğinin kontrol edilmesi amacıyla bu kurallar halihazırda mevcut olup çalışmakta olan bir uygulamanın UML diyagramlarına uygulanmıştır. Dönüştürülen uygulama, asıl uygulama konusunda olduğu gibi fonksiyonelliği sağlamakta ve sunmaktadır.
iv
son kullanıcıya aynı
ACKNOWLEDGMENT
The work on this thesis has been an inspiring, often exciting, sometimes challenging, but always interesting experience. It has been made possible by many other people, who have supported me. I wish to express my gratitude to my supervisor, Assoc. Prof. Dr. Atilla ELÇİ who was abundantly helpful and offered invaluable assistance, support and guidance. And I would like to express my deepest gratitude to my jury members Asst. Prof. Dr. Yıltan BİTİRİM and Asst. Prof. Dr. Mustafa Rıza. I also thank my colleagues and friends for sharing experiences and knowledge during the time of study. Finally, I take this opportunity to express my profound gratitude and dedicate this work to my beloved parents, Zahra Yazdanian Kaleshtari and Ali Mehrolhassani, my brother Mohsen Mehrolhassani and my sister Mahsa Mehrolhassani for their moral support and patience during my study and my life.
v
TABLE OF CONTENTS ABSTRACT ................................................................................................................ iii ÖZET….... .................................................................................................................. iv AKNOWLEDGMENT ................................................................................................ v CHAPTER 1 INTRODUCTION ................................................................................. 1 CHAPTER 2 OVERVIEW OF UML .......................................................................... 5 CHAPTER 3 OVERVIEW OF SEMANTIC WEB AND OWL ................................. 8 CHAPTER 4 MAPPING FROM UML DIAGRAMS TO OWL .............................. 10 4.2 CLASS DIAGRAM .......................................................................................... 11 4.2.1 Introduction.............................................................................................. 11 4.2.2 Visualizing a Class .................................................................................. 11 4.2.2.1 Class name ........................................................................................ 11 4.2.2.2 Attributes .......................................................................................... 13 4.2.2.3 Operations ........................................................................................ 21 4.2.2.4 Attributes, Operations, and Visualization ........................................ 21 4.2.2.5 Responsibilities and Constraints ...................................................... 22 4.2.2.6 Attached Notes ................................................................................. 24 4.2.3 Relationships............................................................................................ 25 4.2.3.1 Binary Association ........................................................................... 25 4.2.3.2 Reflexive Association ....................................................................... 37 4.2.3.3 Association Class.............................................................................. 38 4.2.3.4 N-ary Association ............................................................................. 40 4.2.3.5 Generalization................................................................................... 41 4.2.3.6 Dependency ...................................................................................... 43 4.2.3.7 Aggregation ...................................................................................... 44 4.2.3.8 Composition ..................................................................................... 45 4.2.3.9 Context ............................................................................................. 46 4.2.3.10 Interfaces and Realizations ............................................................... 47 4.3 COMPONENT DIAGRAM ................................................................................ 49 4.3.1 Introduction.............................................................................................. 49 4.3.2 Visualizing a Component diagram .......................................................... 50 4.3.3 Mapping to OWL ..................................................................................... 50 4.4 COMPOSITE STRUCTURE DIAGRAM .............................................................. 51 4.4.1 Introduction.............................................................................................. 51 4.4.2 Mapping to OWL ..................................................................................... 52 4.5 DEPLOYMENT DIAGRAM .............................................................................. 52 4.5.1 Introduction.............................................................................................. 52 4.5.2 Visualizing a Deployment Diagram ........................................................ 53 4.5.3 Mapping to OWL ..................................................................................... 54 4.6 OBJECT DIAGRAM ........................................................................................ 54 4.6.1 Introduction.............................................................................................. 54 4.6.2 Visualizing an Object Diagram ............................................................... 55
vi
4.6.3 Mapping to OWL ..................................................................................... 56 4.7 PACKAGE DIAGRAM ..................................................................................... 58 4.7.1 Introduction.............................................................................................. 58 4.7.2 Visualizing a Package diagram ................................................................ 58 4.7.3 Namespaces ............................................................................................. 59 4.7.3.1 Mapping to OWL ............................................................................. 59 4.7.4 Modeling package dependency................................................................ 60 4.7.4.1 Access ............................................................................................... 60 4.7.4.2 Merge and Import ............................................................................. 61 4.7.4.3 Mapping to OWL ............................................................................. 62 4.8 ACTIVITY DIAGRAM ..................................................................................... 62 4.8.1 Introduction.............................................................................................. 62 4.8.2 Visualizing a Activity Diagram ............................................................... 63 4.8.3 Mapping to OWL ..................................................................................... 64 4.9 STATE MACHINE DIAGRAM .......................................................................... 64 4.9.1 Introduction.............................................................................................. 64 4.9.2 Visualizing a State Machine Diagram ..................................................... 64 4.9.3 Mapping to OWL ..................................................................................... 65 4.10 USE CASE DIAGRAM..................................................................................... 65 4.10.1 Introduction .......................................................................................... 65 4.10.2 Visualizing a Use Case diagram .......................................................... 66 4.10.3 Mapping to OWL ................................................................................. 67 4.11 COLLABORATION DIAGRAM (COMMUNICATION DIAGRAM).......................... 68 4.11.1 Introduction .......................................................................................... 68 4.11.2 Visualizing a Collaboration Diagram................................................... 68 4.11.3 Mapping to OWL ................................................................................. 69 4.12 INTERACTION OVERVIEW DIAGRAM ............................................................. 69 4.12.1 Introduction .......................................................................................... 69 4.12.2 Visualizing a Interaction Overview Diagram ...................................... 70 4.12.3 Mapping to OWL ................................................................................. 70 4.13 SEQUENCE DIAGRAM.................................................................................... 71 4.13.1 Introduction .......................................................................................... 71 4.13.2 Visualizing a Sequence Diagram ......................................................... 71 4.13.3 Mapping to OWL ................................................................................. 74 4.14 TIMING DIAGRAM......................................................................................... 76 4.14.1 Introduction .......................................................................................... 76 4.14.2 Visualizing a Timing Diagram ............................................................. 76 4.14.3 Mapping to OWL ................................................................................. 77 4.15 CHAPTER SUMMARY .................................................................................... 80 CHAPTER 5 CASE STUDY ..................................................................................... 84 5.1 INTRODUCTION ............................................................................................. 84 5.2 UML-BASED WEB APPLICATION .................................................................. 84 5.2.1 Use Case Diagram ................................................................................... 85 5.2.2 Class Diagram .......................................................................................... 86 5.2.3 Object Diagram ........................................................................................ 95 5.2.4 Sequence Diagram ................................................................................... 96 5.2.5 Machine State Diagram ........................................................................... 98 5.3 IMPLEMENTATION AND TESTING ................................................................. 100 5.4 INCONSISTENCY .......................................................................................... 104
vii
5.5
SUMMARY .................................................................................................. 106
CHAPTER 6 CONCLUSION .................................................................................. 107 REFERENCES......................................................................................................... 110 APPENDIX: LN.OWL ............................................................................................ 117
viii
LIST OF FIGURES FIGURE 4-1 UML DIAGRAMS HIERARCHY ........................................................................ 10 FIGURE 4-2 THE UML CLASS ............................................................................................ 12 FIGURE 4-3 UML WASHING MACHINE CLASS .................................................................. 13 FIGURE 4-4 UML VISIBILITY ............................................................................................. 15 FIGURE 4-5 ATTRIBUTE NAME IN UML CLASS .................................................................. 16 FIGURE 4-6 ATTRIBUTE DATA TYPES ................................................................................. 18 FIGURE 4-7 ATTRIBUTE DEFAULT VALUE .......................................................................... 20 FIGURE 4-8 ELLIPSIS IN UML ........................................................................................... 22 FIGURE 4-9 RESPONSIBILITY IN UML ............................................................................... 23 FIGURE 4-10 CONSTRAINTS IN UML CLASS ...................................................................... 23 FIGURE 4-11 UML ATTACHED NOTES .............................................................................. 24 FIGURE 4-12 CLASS ASSOCIATION .................................................................................... 26 FIGURE 4-13 ASSOCIATION PARTS .................................................................................... 26 FIGURE 4-14 ASSOCIATION NAME .................................................................................... 27 FIGURE 4-15 ASSOCIATION ROLES .................................................................................... 29 FIGURE 4-16 ASSOCIATION MULTIPLICITY ....................................................................... 31 FIGURE 4-17 CONSTRAINT ON ASSOCIATION ..................................................................... 32 FIGURE 4-18 A QUALIFIER IN AN ASSOCIATION ................................................................ 33 FIGURE 4-19 NAVIGABILITY ON ASSOCIATIONS ................................................................ 34 FIGURE 4-20 OR RELATIONSHIP BETWEEN TWO ASSOCIATIONS ........................................ 36 FIGURE 4-21 REFLEXIVE ASSOCIATION............................................................................. 38 FIGURE 4-22 ASSOCIATION CLASS .................................................................................... 39 FIGURE 4-23 N-ARY ASSOCIATION ................................................................................... 40 FIGURE 4-24 GENERALIZATION IN UML ........................................................................... 42 FIGURE 4-25 MODELING DEPENDENCY ............................................................................. 44 FIGURE 4-26 AGGREGATION ............................................................................................. 45 FIGURE 4-27 COMPOSITION ............................................................................................... 46 FIGURE 4-28 COMPONENT DIAGRAM ................................................................................ 50 FIGURE 4-29 DEPENDENCY ON COMPONENT DIAGRAMS .................................................. 50 FIGURE 4-30 COMPOSITE STRUCTURE DIAGRAM .............................................................. 52 FIGURE 4-31 DEPLOYMENT DIAGRAM .............................................................................. 54 FIGURE 4-32 CLASS DIAGRAM .......................................................................................... 55 FIGURE 4-33 OBJECT DIAGRAM ......................................................................................... 55 FIGURE 4-34 PACKAGE DIAGRAM ..................................................................................... 59 FIGURE 4-35 PACKAGE ACCESS IN UML .......................................................................... 61 FIGURE 4-36 MERGE IN PACKAGE DIAGRAM .................................................................... 62 FIGURE 4-37 ACTIVITY DIAGRAM ..................................................................................... 63 FIGURE 4-38 FORK AND JOIN IN ACTIVITY DIAGRAM ....................................................... 64 FIGURE 4-39 BASIC SYMBOL FOR MACHINE STATE DIAGRAM........................................... 65 FIGURE 4-40 MACHINE STATE DIAGRAM .......................................................................... 65 FIGURE 4-41 USE CASE DIAGRAM ..................................................................................... 67 FIGURE 4-42 COLLABORATION DIAGRAM ......................................................................... 69 FIGURE 4-43 INTERACTION OVERVIEW DIAGRAM ............................................................. 71
ix
FIGURE 4-44 OBJECT IN SEQUENCE DIAGRAM ................................................................... 72 FIGURE 4-45 MESSAGE TYPES IN SEQUENCE DIAGRAM ..................................................... 73 FIGURE 4-46 SEQUENCE DIAGRAM ................................................................................... 74 FIGURE 4-47 A SECTION OF A SEQUENCE DIAGRAM .......................................................... 75 FIGURE 4-48 TIMING DIAGRAM ........................................................................................ 77 FIGURE 5-1 USE CASE DIAGRAM FOR LN CASE STUDY...................................................... 86 FIGURE 5-2 CLASS DIAGRAM FOR LN CASE STUDY ........................................................... 87 FIGURE 5-3 SEMESTER CLASS ........................................................................................... 88 FIGURE 5-4 USERS CLASS ................................................................................................. 90 FIGURE 5-5 COURSES CLASS ............................................................................................. 91 FIGURE 5-6 ANNOUNCEMENT CLASS ................................................................................ 93 FIGURE 5-7 OBJECT DIAGRAM .......................................................................................... 95 FIGURE 5-8 SEQUENCE DIAGRAM ..................................................................................... 97 FIGURE 5-9 MACHINE STATE DIAGRAM FOR LN APPLICATIONERROR! BOOKMARK NOT DEFINED. FIGURE 5-10 CLASSES IN ONTOLOGY .............................................................................. 100 FIGURE 5-11 CLASSES WITH DETAILED VIEW .................................................................. 101 FIGURE 5-12 RELATIONS BETWEEN CLASSES IN ONTOLOGY ........................................... 102 FIGURE 5-13 CLASSES WITH INDIVIDUALS ...................................................................... 102 FIGURE 5-14 SNAPSHOT OF INSTRUCTORS LIST ............................................................... 103 FIGURE 5-15 COURSE CODES IN APPLICATION ................................................................ 103 FIGURE 5-16 ANNOUNCEMENT RESULT FOR ECON 315 ................................................. 104 FIGURE 5-17 ALGERNON QUERY ..................................................................................... 104 FIGURE 5-18 USERS CLASS INCONSISTENCY .................................................................... 105
x
LIST OF ABBREVIATIONS
UML: Unified Modeling Language OWL: Web Ontology Language XML: Extensible Markup Language XMI: XML Metadata Interchange OWL-S: OWL Services MOF: Meta-Object Facility CWM: Common Warehouse Model PIM: Platform-Independent Model PSM: Platform-Specific Model RDF: Resource Description Framework DAML: DARPA Agent Markup Language OIL: Ontology Inference Layer OWL DL: OWL Description Language OCL: Object Constraint Language URI: Uniform Resource Identifier PHP: Personal Home Page, that stands for PHP Hypertext Preprocessor RDQL: RDF Data Query Language
xi
CHAPTER 1
INTRODUCTION
Nowadays websites and web services are everywhere, as these services and websites are increasing every day, realizing complex business applications and combining them in order to develop a better application has lead to reuse the existing web services instead of redesign and developing them. Software development is a creative process. It requires a deep understanding of the problems to be solved, the involved users and stake holders and their requirements, the ability to find the right level of abstraction from reality, and the creativity to shape a software solution. Many tools are produced to increase creativity and productivity of applications. One of the most popular and powerful tools to do so is UML. UML is a family of visual and graphical notations, supported by single meta-model, that help in expressing and designing software systems, especially software systems which are based on the object-oriented style [7]. Today UML is the standard for modeling object-oriented software for considerable number of web services and web applications, and has been accepted by societies and system developers throughout the world, also so many tools support software and business modeling using UML. On the other hand there is a new proposal to increase the capability of the existing web, this new proposal is “Semantic Web” which is not something distinct from the existing one but which enables people and machines to understand and work together by giving well-defined meaning to information. To provide
1
expressiveness and to support inferencing, many languages are proposed which OWL in one of them [42]. OWL provides more advanced semantic concepts than other languages [8]. “OWL permits the definition of sophisticated ontologies, a fundamental requirement in the integration on heterogeneous information content. OWL ontology will also be important for the characterization of interoperable services for knowledge-intensive processing on the web” [10]. The popularity, flexibility and ease of use of UML in one hand, and OWL which is developed to satisfy the requirements for a language to support the Semantic Web on the other hand has lead to several proposals to reuse current web applications, which are designed by UML, for future web, the Semantic Web. To do so, many investigations have been done but still absence of one standard approach is obvious. Due to the fact that OWL is more precise than UML, there is a high probability of failing to retain all concept of UML in conversion to OWL. Some researches have been done in reverse way from OWL to UML. One approach which is proposed by [11] presents a visual modeling of OWL ontologies which are based on UML. This study tries to invent a UML profile which captures and visually models the language primitives offered by OWL. Another study tries to export a UML model into formats which are used to interchange data like XML [12] or XMI [13], then through some processes tries to extract ontology out of XMI file. In another study author(s) made an effort to do two side conversions between UML models and OWL-S. The aim of the study was to produce a UML profile for semantic web services which enables the use of high-level graphical models as an integration platform for semantic web services, however only OWL-S to UML is covered to demonstrate that such mapping is possible in both directions [14].
2
Some other investigations are done in order to reach to a standard and straightforward conversion rules from UML models to OWL [3], some proceed in the inverse way from OWL to UML and used intermediate tools in order to reach the goal, and some attempted to graphically visualize OWL into UML models [6]. Among all the studies that have been done before, however none of them found a perfect solution, there is something missing in between, and brings us to this question, “what about DIAGRAMS?” , and its due to the fact that no one before took UML diagrams kind into consideration in conversion from UML to OWL. UML consists of thirteen different kinds of diagrams, and each has its own functionality and is provided to accomplish specific task(s) in the design phase of any application. Therefore we decided to go over all thirteen UML diagrams and inspect for possible mapping, and if so the conversion will be done by considering all details of the diagram. The scope of this study is to present an approach to develop ontology based applications for semantic web using OWL ontologies derived from the business domain logic described by the well-established visual modeling language UML. Description logic based ontology languages such as OWL are usually defined in terms of an abstract (text-based) syntax and most care is spent on the formal semantics. The absence of a visual syntax has lead to several proposals of a particular visual notation for the classic description logic. Conversion from UML to OWL should be done in a very precise way because it is not as straightforward as it seems. It is quite likely that there are multiple alternatives in OWL for representing of elements of the same UML construct and we would probably need best practices for the same. The study will devise a
3
straightforward standard approach for converting UML diagrams to OWL to be used by developing tools to produce an ontology based application. The application description generated by converting UML design is going to be used as basis for OWL ontology. In this chapter we introduced the aim of this study; the rest of the study would be as follow: Chapter 2: a brief introduction to UML. Chapter 3: Semantic Web and OWL are introduced briefly. Chapter 4: is dedicated for inspecting possible conversion of UML diagrams into OWL. Chapter 5: a casy study to check the conversion rule for accuracy. Finally findings and discussions will be in chapter 6; Conclusion.
4
CHAPTER 2
OVERVIEW OF UML
UML is an extraction of three major notations and a many modeling techniques drawn from widely distinct methodologies that have been in practice over the previous decades [39]. UML has been formally under development since 1994 [43]. Since that time it has had an irrefutable impact on the way we view systems development. Regardless of early competition from existing modeling notations, UML has become the practical standard for modeling object-oriented software for considerable number of Information technology shops. UML has been accepted by societies throughout the world, and today many modeling tools support software and business modeling using UML. Due to the fact that UML modeling increases the level of abstraction throughout the analysis and design process, it is easier to identify patterns of behavior and thus define opportunities for refactoring and reuse, as result UML enables system developers to specify, visualize, and document models in a way that supports scalability, security, and etc. Therefore, UML facilitates the invention of modular designs resulting in components that accelerate development and help insure consistency
across
systems
and
implementations.
Dissimilar
to
previous
methodologies, there is no need to change the way you work just to suit the demands of a seller. In order to customize UML models to a particular application type or technology UML uses extension mechanisms. While the extension mechanisms are a
5
little limited today, they do provide substantial support for tailoring UML to the needs of a specific project, whether the project's goal is a transaction-oriented application, real-time, e-commerce or Web service, and without regarding of the subject domain. An UML profile contains predefined sets of extension mechanisms for a particular environment. In the UML specification itself you will find profiles for J2EE, COM, .NET, and CCM development. Each profile provides customized modeling elements that map to the common elements and features in each of these architectures. This method enables the modeler to focus time and energy on the project content instead of the unique modeling features of the implementation domain. UML is based on the MOF which defines the foundation for creating modeling languages used for object modeling, such as UML, and for data modeling, such as the CWM. In addition The MOF defines standard style for the main elements of a model so that they can be saved in a common repository and exchanged between modeling tools and languages. XMI provides the technique to implement the sharing of these modeling elements between modeling tool sellers and between repositories. This means, for example, that a project can use one tool for developing a PIM using UML diagrams and switch to another tool to refine the model into a PSM using a CWM model to generate the database schemas. This standards-based technique places the choice of tools in the hands of the modelers instead of the tool vendors. Models that are based on UML can be detailed enough to generate code or even the entire application. Automated test suites can verify the accuracy of the model. When come together with tools to compile the UML model, the model can be executed even before any code exists. A complete executable UML design may be
6
deployed to multiple platforms that each use different approaches. A model might be implemented and developed in one place using a particular language or database configuration, and at another location with a totally different setting. UML grew out of the increasingly complex challenge to build systems that not only met users' requirements but also that could resist the ever-changing technological environment. Change, complexity, and speed conspired to focus critical attention on how to build robust, durable systems. One result was a standard language for modeling systems, the UML [9].
7
CHAPTER 3
OVERVIEW OF SEMANTIC WEB AND OWL
The Semantic Web is a vision for the future of the Web, in which information is given explicit meaning, making it easier for machines to automatically process and integrate information available on the Web. The Semantic Web will build on XML's ability to define customized tagging schemes and RDF's flexible approach to representing data. The first level above RDF required for the Semantic Web is an ontology language what can formally describe the meaning of terminology used in Web documents. If machines are expected to perform useful reasoning tasks on these documents, the language must go beyond the basic semantics of RDF Schema [44]. OWL [42] is intended to be used when the information contained in documents needs to be processed by applications, as opposed to situations where the content only needs to be presented to humans. OWL can be used to explicitly represent the meaning of terms in vocabularies and the relationships between those terms. This representation of terms and their interrelationships is called ontology. OWL has more facilities for expressing meaning and semantics than XML, RDF, and RDF-S, and thus OWL goes beyond these languages in its ability to represent machine interpretable content on the Web. OWL is a revision of the DAML+OIL web ontology language incorporating lessons learned from the design and application of DAML+OIL. OWL provides three increasingly expressive sublanguages designed for use by specific communities of implementers and users. OWL Lite supports those users
8
primarily needing a classification hierarchy and simple constraints. For example, while it supports cardinality constraints, it only permits cardinality values of 0 or 1. It should be simpler to provide tool support for OWL Lite than its more expressive relatives, and OWL Lite provides a quick migration path for thesauri and other taxonomies. Owl Lite also has a lower formal complexity than OWL DL [42, 8]. OWL DL supports those users who want the maximum expressiveness while retaining computational completeness (all conclusions are guaranteed to be computed) and decidability (all computations will finish in finite time). OWL DL includes all OWL language constructs, but they can be used only under certain restrictions (for example, while a class may be a subclass of many classes, a class cannot be an instance of another class). OWL DL is so named due to its correspondence with description logics, a field of research that has studied the logics that form the formal foundation of OWL [42, 8]. OWL Full is meant for users who want maximum expressiveness and the syntactic freedom of RDF with no computational guarantees. For example, in OWL Full a class can be treated simultaneously as a collection of individuals and as an individual in its own right. OWL Full allows an ontology to augment the meaning of the pre-defined (RDF or OWL) vocabulary. It is unlikely that any reasoning software will be able to support complete reasoning for every feature of OWL Full [42, 8].
9
C CHAPTE ER 4
MAPPIN NG FROM M UML DIA AGRAMS S TO OWL L
In the previous ch hapters we haad an overviiew of UML, Semantic web w and OW WL and a gave th he prominennces of eachh. We also clarified c why conversio on of UML to OWL O is imp portant and expressed e thee advantagess of this convversion. UML consists of thirteen t diffeerent kinds of o diagrams [39], and eacch has its ow wn functionality f y and is proovided to acccomplish sp pecific task(s) in the deesign phase of any a applicattion. In thiss chapter we are goingg to analyzee thirteen UML diagram ms inspecting i fo or possible mapping, m andd if so the coonversion will be done by b considerinng all a detail eleements of thhe diagram. The rest of this chapterr is organizeed to cover all a thirteen t diag gram and wee will go oveer them:
Figure 4-1UML Diagrams Hierarchy H [43]
4.2
Class Diagram
4.2.1 Introduction A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them. Class diagrams also show the properties and operations of a class and the constraints that apply to the way objects are connected. The UML uses the term feature as a general term that covers properties and operations of a class [31]. 4.2.2 Visualizing a Class 4.2.2.1 Class name A class is a definition for a resource. It includes information that describes the features of an entity and how it can be used. In contrast, an object is a uniquely identifiable entity that conforms to the rules defined by the class. In software terms, code is written as a set of classes and references to behaviors defined by the classes. The information actually created and manipulated is owned by objects that conform to the class descriptions. Objects are represented by rows in a database, records in files, or areas of memory in a computer. One class definition describes many objects of the same type. Each class definition contains at least a unique name. This name defines the class in the repository so that any time the same name is referenced it is associated with the same repository definition. A class can also contain attributes and operations that describe everything necessary to create (instantiate) an object of the defined type [7]. To support definitions for identity, attributes, and operations, a UML class definition provides an icon with three predefined compartments to contain and organize this information: name, attributes, and operations. These compartments (Figure 4-2) correspond to the common elements of a class definition. In addition, UML supports user-defined compartments so that the modeler can add project-
11
related information or anything else that she finds useful. When a class is presented on a Class diagram, the name compartment is the only compartment that must be visible. The attributes, operations, and user-defined compartments may or may not be displayed, depending on the purpose and goals for presenting the diagram [31].
Figure 4-2 The UML class
Mapping to OWL Both UML and OWL consists of classes. A class in OWL is a set of zero or more instances. A class in UML is a more general construct, but one of its uses is as a set of instances. The set of instances associated at a particular time with a class is called the class’ extent. There are subtle differences between OWL classes and UML classes which represent sets. In UML the extent of a class is an object consisting of instances. An instance consists of a set of slots each of which contains a value drawn from the type of the property of the slot. The instance is associated with one or more classifiers. In OWL, the extent of a class is a set of individuals, which are represented by names. Individual is defined independently of classes. There is a universal class Thing whose extent is all individuals in a given OWL model, and all classes are subclasses of Thing. The main difference between UML and OWL in respect of instances is that in OWL an individual may be an instance of Thing and not necessarily any other class, so could be outside the system in a UML model. Instances in UML could be mapped to Individuals in OWL as follow:
12
In the case the individual is instance of Thing mapping could be as follow:
Figure 4-3 demonstrates a UML class with WashingMashin as the name, which could be mapped into owl:class that is it’s equivalent element in OWL. The mapped syntax is shown below:
Figure 4-3 UML Washing Machine Class
A class name must be unique within a package. But the same class name may occur in multiple packages. To clarify which class you mean to reference you must qualify the class name with the name of the package that owns it. The format for a fully qualified class name is Package_Name :: Class_Name, therefore conversion from UML to OWL should be done in a very precise way because some characters are not accepted as class name in OWL like :: and numbers at the beginning of the class name. 4.2.2.2 Attributes The attributes compartment contains definitions for all the information that an object owns. Like the other compartments, it is simply a list of like items, a list compartment. It differs from other compartments in two ways. It may only contain attributes and it always appears in the same relative location within the class icon,
13
just below the name compartment. The attribute compartment contains all the information that an object can own [39]. Each attribute needs to be defined to the level at which the application can insure the integrity of the attribute and of the system in which it is used. To accomplish this, a UML attribute definition includes the following elements [7]:
Visibility
Derived (true/false)
Name
Data type
Multiplicity
Default value
Property string
The full form of an attribute is: visibility name: type multiplicity = default {property-string}
Visibility Visibility is a subject that is simple in principle but has complex subtleties. The simple idea is that any class has public and private elements. Public elements can be used by any other class; private elements can be used only by the owning class. However, each language makes its own rules. Although many languages use such terms as public, private, and protected, they mean different things in different languages. These differences are small, but they lead to confusion, especially for those of us who use more than one language. The UML tries to address this without getting into a horrible tangle. Essentially, within the UML, you can tag any attribute or operation with a visibility indicator. UML provides four abbreviations for visibility: + (public), – (private), ~ (package (Unknown)), and # (protected). These four levels are used within the UML
14
meta-model and are defined within it, but their definitions vary subtly from those in other languages. Figure 4-4 shows all the possible visibilities provided by UML in a class.
Figure 4-4 UML visibility
Mapping to OWL The visibility term in UML can provide the ability to for system or objects in the system to hide what it does or contain from other objects and from the outside world. As OWL is to represent static data and each ontology or system that have access to the OWL file for example by importing that ontology using owl imports whether to use part of the imported ontology or whole, the complete ontology is accessible. Therefore the visibility essences of UML have no equivalent in OWL and are treated like public members. Such capability must be provided by some other tools or languages to OWL. Derived A slash (/) in front of an attribute name identifies the attribute as containing a derived value. The absence of the slash indicates a base value. A derived value is one that's computed, or figured out, using other data and a rule or formula. A base value must be provided because there is no other way to obtain the value. When an attribute is determined to be derived, there are more design decisions that need to be
15
addressed regarding the handling of the data, so the derived flag is used as a reminder to the modeler until there is time to resolve the handling of the data. Base values are designated by the absence of the derived symbol. Mapping to OWL UML allows a property to be derived from other model constructs, for example a composition of associations or from a generalization. That a property is derived can be represented as an annotation in OWL. The actual derivation rule cannot in general be represented in OWL (OWL does not support arithmetic, for example). Derivation rules in UML are expressed in OCL [40], and there is no general translation of OCL to OWL. Name The attribute name is required. The name must be unique within the class. Attribute names should be as descriptive as possible to avoid confusion. By convention, a one-word attribute name is written in lowercase letters. If the name consists of more than one word the words are joined and each words other that the first word begins with an uppercase letter. The list of attribute names begins with a line separating them from class name as shown in Figure 4-5.
Figure 4-5 Attribute name in UML class
Mapping to OWL As mentioned before attributes within each class have unique names, but the same attribute with same name may exist in another class, therefore we will have two attributes with same name in two different classes. The OWL property name must be unique within the ontology. One solution to this issue is to use a combined name for
16
property in OWL. This could be done by using attributes class name before its name. As a result well have a unique attribute name in our ontology. The following is converted attribute to OWL property:
Another issue is the scope of the attribute that is whether it is associated to its own class of another class? This is important because there are two different property types in OWL and each have a range and a domain. One case is the relation class’s owned attribute between Class and Property, which generates the representation of a class as a bundle of owned properties. An instance of Class’s owned attribute Property would translate as properties whose domain is Class name and the range is the type of Property. The UML class’s owned attribute instance will be mapped to owl:ObjectProperty if the type of Property were a UML Class, that means the relationships among classes in UML are mapped to OWL by owl:ObjectProperty [8], otherwise is will be mapped into owl:DatatypeProperty [8]. In case of data property the translation would be as follow:
And in case of object property the corresponding mapping would be as follow:
Therefore the converted UML owned attribute of Figure. 4-5 will be as follow whose domain is a class and the range in integer data type:
17
Data type An attribute type identifies a classifier (not class) that explains the kind of information that can be stored in the attribute. A classifier may be: •
A reference to a UML primitive Data Type (Integer, UnlimitedInteger, or String)
•
An enumeration such as Boolean
•
A reference to a language-specific type such as float, long, short
The UML attribute definition only allows for one data type. Figure 4-6 show a sample data types in UML.
Figure 4-6 Attribute data types
Mapping to OWL Data types are used in conversion of UML attribute to owl:DatatypeProperty [8]. Most of the data types defined in UML are supported in OWL therefore translation from UML to OWL is straight forward as we will define the data type as the range of the owl:DatatypeProperty.For example conversion of first attribute is Figure 4-6 will be done in the following way as the String data type will be mentioned as the range of the property.
18
Multiplicity When an attribute may have only one value, you can use a multiplicity range of [1..1], the abbreviated form [1], or even let the attribute assume a default multiplicity of 1. . An attribute may also contain more than one value. The multiplicity format will be like this: name [: type] [multiplicity] [= default]. As an instance we will define that the attribute Name in Figure 4-6 would get two different names. In UML it’s expressed as follow: name [: String] [2] Mapping to OWL Mapping multiplicity on attributes to OWL will be done using owl:Restriction and owl:Cardinality on data type definition of the attribute. For example the conversion of name [: String] [2] will be done using owl:Restriction on eventName property of event class mentioning that the cardinality of its string data type is 2. The OWL equivalent is showed below: 2
Default value UML adds the default value to the attribute definition string using an assignment operator (=) followed by the default value expression. The default value expression may be a single value or a string expressed in some language like the Object Constraint Language or an implementation language. During modeling it can
19
work equally well to use free-form text in the default to capture what you want to do. Then return later to iron out the specific language. Default values are applied to the attribute when an object is created. They may appear in the constructor as hard-coded values. They may be defined as class-level or static values that can be referenced in the constructor. Static values are defined by underlining the attribute in class diagram. Figure 4-7 shows 25 as default value for capacity attribute.
Figure 4-7 Attribute default value
Mapping to OWL The default values in UML are demonstrated in OWL using owl:hasValue to assign the specific value to the attribute. The corresponding code for OWL is as below: 1 25 The above come defines that the property named venueCapacity has cardinality 1 which means it can only take one value and hasValue equal to 25 that defines its default value. Property string The property string is like a catchall for anything you might want to include in the definition but for which there is no designated location. The most common use of the property string is to express the rules required to guarantee the integrity of the attribute value whenever another object attempts to change it. Any time another object tries to alter the attribute value; it must pass the rules established in the
20
property string. These rules may be expressed as constraints on the value and may even use the OCL defined by UML. The constraints are implemented/enforced in any method that attempts to change the attribute value. Mapping to OWL As mentioned before property strings in UML are expressed in OCL, and there is no general translation of OCL to OWL. 4.2.2.3 Operations UML allows the specification of behavioral features, which are essentially programs. One use of behavioral features is to calculate property values. Other programs would presumably have side effects. One of the Facilities of UML supporting programs is operations. Mapping to OWL The nature of OWL is to demonstrate static information and prepare them in such a way that is readable for machines so they can do computation on information provided to them by OWL. As result OWL generally is not able to express operations defined in UML therefore we propose to place a reference in OWL to refer to the algorithm, procedure, and … used in the program. Another way is to. Another possibility is that operations are rules which are defined by UML, in case of rules there is conversion possibility to OWL but we will not deal with rules as it is out of scope of our study and we will leave it to rule based systems. At this level we leave operations to programming.
4.2.2.4 Attributes, Operations, and Visualization Sometimes it might be helpful to show some but not all of the attributes or operations. To indicate that you’ve only shown some of them, you follow the list of
21
the ones you’ve show with three dots”…”. This is called an ellipsis, and omitting some or all of the attributes or operations is called eliding a class. Figure 4-8 shows eliding.
Figure 4-8 Ellipsis in UML
Mapping to OWL Ellipsis and eliding are used to display UML class in a more abstract way to not make class diagrams too busy and more understandable. Such a feature is not provided in OWL and it is not able to display a class in abstract fashion therefore such ellipsis end eliding are not convenient for mapping UML class to OWL class and class diagrams should be as detailed as possible to extract enough information in order to generate OWL class [22, 17]. As result there would be no mapping from UML ellipsis and eliding to OWL. 4.2.2.5 Responsibilities and Constraints The class icon enables you to specify still another type of information about a class. In an area below the operations list, you can show the class's responsibility. The responsibility is a description of what the class has to do – that is, what its attributes and operations are trying to accomplish. A washing machine, for example, has the responsibility of taking dirty clothes as input and producing clean clothes as output. Figure 4-9 demonstrates responsibility in WashingMachine class.
22
Figure 4-9 Responsibility in UML
A slightly more formal way is to add a constraint, a free-form text enclosed in curly brackets. The bracketed text specifies one or more rules the class follows. For example, suppose in the washing machine class you wanted to specify that the capacity of a washer can be only 16, 18, or 20 pounds (and thus “constrain" the washing machine class's capacity attribute). You would write {capacity = 16 or 18 or 20 1bs} near the washing machine class icon. Figure 4-10 shows how to do it.
Figure 4-10 Constraints in UML class
Mapping to OWL As responsibilities are not exactly elements of UML class and are extra description about what the class has to do and what goals its operations and attributes are seeking for, we can keep these information as annotations to our ontology. Such conversion
could
be
done
using
six
predefined
annotation
properties
(owl:versionInfo, owl:annotationProperty, rdfs:label, rdfs:comment, rdfs:seeAlso and
23
rdfs:isDefinedBy) of OWL. The class responsibility in Figure 4-9 would be mapped to the following OWL code: Responsibility Take dirty clothes as input and produce clean clothes as output
But for constraint the situation is slightly different. The UML works with still another – and much more formal – way of adding constraints that make definitions more explicit. It's an entire language called OCL. OCL has its own set of rules, terms, and operators. As mentioned before there is no straight forward translation from OCL to OWL [16]. 4.2.2.6 Attached Notes Since it is impossible to provide a notation for everything that could be expressed in a project, UML provides the capability to attach freeform text to any element in the model. Comments may be attached to individual attributes, operations, associations, messages, objects, anything in a UML model. Figure 4-11 shows an example for attached notes.
Figure 4-11 UML Attached Notes
24
Mapping to OWL Mapping UML attached notes to OWL is straightforward and could be done using owl:annotationProperty. The corresponding OWL code for Figure 4-11 is mentioned below: changes Changes to this class will be discussed at the Thursday team meeting
4.2.3 Relationships A software application requires a set of resources. To use them you need to describe each resource using a class definition. Classes describe the types of resources, their purpose, and the features that they provide, including attributes and operations. But to coordinate the interaction of these resources, you need to explain how they can communicate. To communicate, they need to be aware of one another. Just as people use various means to communicate like phone calls and mail or e-mail, objects also need to define a means to communicate. They need to define a type of relationship. UML relationships come in three different types: association, generalization, and dependency. 4.2.3.1 Binary Association In a Class diagram, a binary association documents the rules that govern one relationship between two classes of objects. The association is a rule that explains what is allowed. In an Object diagram, an actual relationship is called a link. An association is a rule. A link is a fact. Figure 4-12 shows an association connecting the Venue class and the Event class. The Venue class defines what a venue object is and what it can do. The Event class defines what an event is and what it can do. The
25
association defines a single type of relationship that can be established between venues and events, one reason why these types of objects need to communicate.
Figure 4-12 Class Association
A complete association definition is built with three parts: an association line between the classes and two association ends. The association line and its name define the identity and the purpose of the relationship. The association ends each define the rules about how the objects of the classes at each end may participate. Figure 4-13 demonstrates these relations.
Figure 4-13 Association Parts
Association name The name of an association is very important and necessary, because it expresses to the reader the intent of the relationship. Each association represents an investment of time and effort to establish the relationship, preserve its integrity, and ensure its proper usage. When the name is vague, it introduces confusion and debate, increasing cost and reducing effectiveness in the modeling process. The usual way to name an association is with a verb or verb phrase. Figure 414 shows the same association modeled with two different names, using a verb "hosts" and a verb phrase "is hosted by". The position of the name is not critical. The name only needs to be somewhere in the middle of the line between the two classes.
26
Keep it near enough to the line so that the reader of the diagram clearly understands what the name is referring to. Also, keep the name away from the association ends, where you will be adding a lot of information.
Figure 4-14 Association Name
UML assigns one association name with the understanding that the relationship can be read in the opposite direction by reversing the meaning. In other words, the top association name in Figure 4-14 is read with the understanding that if a "venue hosts an event" then the reverse must be true, that is "an event is hosted by a venue." So you would model one or the other of the associations in Figure 4-14, not both. This is very important issue and in conversion of UML to OWL. Mapping to OWL Earlier we mentioned that relations in UML are to be mapped into OWL properties, but depend on the situation whether the relation is between a class and its attributes or between two classes we could use owl:DatatypeProperty or owl:ObjectProperty. Here because the relation is between two classes we have to use owl:ObjectProperty. As we know each property in OWL has a range and a domain the domain and the range would be classes. Consider Figure 4-14, to map this relation to OWL we have to define an object property whose name is venueHosts (as we agreed before to use combine name for uniqueness). The corresponding OWL code is as below:
27
Association end In order to represent the rules mentioned before, UML treats each association end as a separate and distinct entity with its own rules. That is, a venue's participation in the "hosts" association is different from the event's participation in the "hosts" association as modeled in Figure 4-14. Each end of the association needs to explain, for instance, what role the object at that end plays in the relationship, how many objects of that type may participate in the relationship, and if there may be many participating objects, whether they have to be in some order. The association end also specifies whether there's some feature of the object that could be used to access it, and whether the object on one end can even access the object/s on the other end. Each end of the association includes some or all of these defining features:
Roles
Interface specifier
Visibility
Multiplicity
Constraints
Qualifier
Navigability
Roles A role name explains how an object participates in the relationship. Role names describe the association in terms of how each type of object (venue and event, in our example) participates in the association. Because both association names and role names help describe the nature of the relationship, the role names may be used with or in place of the association name. Place of the role name is at the end of the
28
association line and next to the class that it describes. The exact position is not critical. Just it has to be near the end of the association near the class.
Figure 4-15 Association Roles
Mapping to OWL Roles in UML that are placed near each end of the associations are to be converted to some annotation or comments in OWL because they are not name of the associations. In some cases roles are replaced with association name, in such a case roles could be considered as association name. The conversion of Figure 4-15 is to be done using rdfs:comment, after declaration of range and domain of the association as below: host hosted
Interface specifier A class defines a set of operations called an interface. In any given association only one or a few of those operations might be needed. For example, the theater system performance class is used for a variety of reasons. The marketing subsystem accesses the features of a performance that support assigning prices. The sales subsystem accesses the features that support finding and choosing available seats at the performance. The interface specifier is paired with the role name in the format "role name : Interface", as in "performance : IPricing", and "performance : IAvailability."
29
The interface specifier is a way to define the required features without dictating either the class that provides them or the implementation. It simply states that for the relationship to work there are specific features that must be supported. Mapping to OWL As mentioned before just like operations interfaces are also part of the behavioral features of the UML and could not be converted into OWL. Visibility Also illustrates the visibility notation for role names. Visibility was covered fully before, and here we are using the exact same concepts, except that the visibility refers to who can access the role name. Mapping to OWL The visibility is covered previously and according to that section all visibility rules will be considered as public in OWL which is the nature of the OWL and therefore there is no mapping for it. Multiplicity Association multiplicity refers to the valid number of objects that may be related under the rules of the association. Multiplicity may express a range of values, a specific value, a range without limit, or a set of discrete values. There is one significant difference between the attribute multiplicity notation and the multiplicity notation used with association ends: attribute multiplicity is enclosed in square braces ([]), and association multiplicity stands by itself. Figure 4-16 shows a multiplicity.
30
Figure 4-16 Association Multiplicity
Mapping to OWL When an association is established between two classes it is considered as bidirectional association in UML that is for example in Figure 4-16 when the association shows that Venue class hosts Event class the reverse association is also exists and that is Event class is hosted by Venue. In mapping to OWL if we don’t consider this default of UML then the conversion will not be fully correct because an object property will be created whose domain is Venue and range is Event and this is just half of all and in addition another object property should be created with of course different name whose range is the domain of first object property and its domain is the range of that object property and the second (or first) object property should be defined as inverse of the other in order to demonstrate the full relation between two classes. To demonstrate multiplicities defined on association ends of Figure 4-16 OWL Cardinality and Restriction are used. OWL uses Restrictions to represent Cardinality. So in addition to map Class to OWLClass, some OWLRestrictions will be generated based on multiplicity definitions of the association ends and corresponding RDFSsubClassOf relationships between OWLClass and OWLRestriction will also be created.The following is the OWL description of Figure 4-16.
31
0 1
Constraint A constraint defines a restriction that needs to be enforced on a modeling element to insure its integrity throughout the life of the system. A constraint is used to define rules, and can help us with this new set of requirements. The format of a constraint is really just a string of text (in a specific language) that can be attached to almost any element in your model. The language of the constraint may be OCL, a programming language, or even your own written language, such as English, German, or French. Since constraints are really just strings, you can add as many constraints as you need between the pairs of braces {}. Constraints document the implementation requirements for the end of the association. They are implemented in the methods that create and alter the object references that represent the relationship.
Figure 4-17 Constraint on association
32
Mapping to OWL As mentioned before there is no general translation of OCL to OWL. Therefore UML constraint could not be mapped into OWL unless in the conversion process we decide to keep them as annotations or comments to make the semantic of our ontology richer. Qualifier A qualifier works very much like a key on an indexed file. It provides a means to go directly to the object you want. The qualifier defines an attribute of the referenced objects and uses it as a key to get direct access to a specific object. From a modeling standpoint, this simply specifies the desire or the requirement to have this type for access. The goal is to then to find an implementation that can satisfy the desired direct access with the specified key. To model a qualifier as shown in Figure 4-18 you must identify the type of object that wants to use the access, and the type of object that provides the access. The qualifier is placed next to the type of object that wants to use it.
Figure 4-18 A Qualifier in an association
Mapping to OWL OWL cannot adequately express some qualifiers that are used to define constraints on properties. For example, OWL cannot directly represent the semantics of the ‘key’ qualifier which is used to indicate that the value of a property must be unique for all instances of a particular class. As we know the nature of ‘key’ is its uniqueness. Functional property of owl (owl:FunctionalProperty) could be used to enforce an individual to only have one unique value for its property but still it
33
doesn’t represent the concept of ‘key’ and does not imply that every individual must have value for their functional property. Navigability Navigability describes the need for an object to access another object by "navigating across the link." In other words, setting the navigability attribute of an association end determines whether the object at the other end of the link can access the object on the navigable end of the link. Navigability is modeled with an arrow on the end of the association. If the arrow is present, that end of the association is navigable. If the arrow is absent then that end of the association is not navigable. Figure 4-19 shows that the navigability on the event end of the hosts association is true. We know this because the navigation arrow is visible on the end of the association pointing to and touching the Event class. This means that the events are visible to the venue at the other end of the link.
Figure 4-19 Navigability on associations
When both ends of the association are navigable, it might be expected both ends to have arrows on them. Unfortunately this is another place where default reasoning can cause confusion. When both ends are navigable, most tools use the default that does not show any arrows. The reasoning is that most associations are bidirectional. The exception is unidirectional navigation. To save time and effort, it can be easier to assume that all associations are bi-directional unless otherwise modeled. Mapping to OWL In OWL when an object property is constructed it demonstrates a unidirectional association because it has one range and one domain which the range
34
specifies the association end that the arrow belongs to. For example in Figure 4-19 the object property named venuHosts has domain Venue and range Event which tells us that direction of association is from Venue to Event. This diagram is equivalent to a object property in OWL which its domain is Venue and its range is Event without any owl:InverseOf attached to it, so it will demonstrate a one way associations as shown in Figure 4-19. One important issue in this conversion is that we have multiplicity on both end but as the arrow shows one way association and we are not going to generate the inverse property therefore we will lose the multiplicity on the Venue side because in each OWL property the multiplicity could be applied only to the range of the property as result to show the multiplicity on Venue side we have to express the inverse property as well which is not as part of the diagram in Figure 4-19. Related OWL conversion it as below: 0
Constraint on Associations Constraints on associations are used to handle a situation where two associations are mutually exclusive. For example Figure 4-20 shows the logical OR [28] construct. The OR construct id signified bye {or} on a dashed line that connects two association lines. It models that a high school student choosing either an
35
academic course of study or commercial one. Other logical constructs like “AND” and “NOT” could be used as constraints on associations [28].
Figure 4-20 OR relationship between two associations
Mapping to OWL To shows logical constraints like “OR”, “AND” and “NOT” in OWL three properties are used. These three are “owl:IntersectionOf” for “AND”, “owl:unionOf” for “OR” and “owl:complementOf” for “NOT”. To map OR constraint in Figure 4-20 we have to define an object property with the name ”highSchoolStudentShooses” whose domain is “HighSchoolStudent” and its range is union a collection which the collection specifies those classes that are participating in OR construct as the range for “”highSchoolStudentShooses” object property. The corresponding OWL code is shows below:
In the same fashion the “AND” logical constraint could be mapped just instead of “owl:unionOF” we have to use “owl:intersectionOf” as follow:
36
“NOT” logical construct could be mapped to OWL using “owl:complementOf” with any of ”owl:unionOf” or “owl:intersectionOf” as follow:
4.2.3.2 Reflexive Association All of the association examples so far have modeled relationships between objects of two different classes, such as Event and Venue. There are times, however, when the participating objects belong to the same class. For example, one venue manager might provide backup for another venue manager. When the participating objects are in two different classes, the association line comes out of one class and into another class. When the objects all belong to the same class the association has to come out of the class and return back to the same class, as shown in Figure 4-21.
37
Figure 4-21 Reflexive Association
A reflexive association is a very common place to use role names. In a binary association, the association reads almost like a sentence using the class names. In a reflexive association the meaning may not be quite as clear. Without the role names in the Figure 4-21 diagram, the association would read, "one VenueManager is associated with zero or more VenueManagers." With the role names it reads, "VenueManagers functioning as coordinators always work with a VenueManager functioning as an auditor." Mapping to OWL The conversion of reflexive associations into OWL is straightforward. Like a binary association which has a range and a domain, the mapping of reflexive association has domain and range but the target of range is the same class that domain points to. The OWL code without representing multiplicity is as below:
4.2.3.3 Association Class In an object oriented model all information is modeled as attributes. Attributes reside within classes. So information about an association must be defined as
38
attributes in a class. But how do we model the fact that the information describes an association, and not an entity? An association class is much like any other class. The only real difference is in how you found the need for the class. Where most classes describe an entity, something that you can see or touch, an association class describes a relationship. Because an association class is just another class, it can participate in other associations. An association class can have associations to other classes. Figure 4-22 show an association class for the association between a Player class and Team class named Contract.
Figure 4-22 Association Class
Mapping to OWL The mapping to OWL could be done by defining a class named Contract and two functional properties that demonstrate associations between Contract-Player and Contract-Team. The functional property between Contract and Player will have domain as Contract class and range as Player class. The functional property between contract and team will have same domain and range as Player Team class. The following is OWL code for association class in Figure 4-22: dfs:domain rdff:resource="#users"/> > dfs:domain rdff:resource="#users"/> dfs:domain rdff:resource="#co ourses"/>
