Axiomatized Relationships Between Ontologies

by

Carmen Chui

A thesis submitted in conformity with the requirements for the degree of Master of Applied Science Graduate Department of Mechanical & Industrial Engineering University of Toronto

c Copyright 2013 by Carmen Chui

Abstract

Axiomatized Relationships Between Ontologies

Carmen Chui Master of Applied Science Graduate Department of Mechanical & Industrial Engineering University of Toronto 2013

This work focuses on the axiomatized relationships between different ontologies of varying levels of expressivity. Motivated by experiences in the decomposition of first- order logic ontologies, we partially decompose the Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) into modules. By leveraging automated reasoning tools to semi-automatically verify the modules, we provide an account of the meta-theoretic relationships found between DOLCE and other existing ontologies. As well, we examine the composition process required to determine relationships between DOLCE modules and the Process Specification Language (PSL) ontology. Then, we propose an ontology based on the semantically-weak Computer Integrated Manufacturing Open System Ar- chitecture (CIMOSA) framework by augmenting its constructs with terminology found in PSL. Finally, we attempt to map two semantically-weak product ontologies together to analyze the applications of ontology mappings in e-commerce.

ii Acknowledgements

I would like to thank Professor Michael Gr¨uninger for his support and guidance over the course of my undergraduate and graduate studies. It is through our various discussions and brainstorming sessions that the theme for this thesis arose. His passion and enthu- siasm to explain concepts found within the fields of ontologies and logic have guided me throughout the course of writing this thesis. As well, his suggestions and criticisms have been invaluable in this work. Thank you to the members on my thesis committee, Professor Mark Fox, Professor Li Shu and, my supervisor, Professor Michael Gr¨uninger.I would also like to thank Mark van Berkel of Hunch Manifest, Inc. for providing an opportunity to explore and analyze the applications of ontologies and their mappings in e-commerce. During my time as a member of the Semantic Technologies Lab, I have been privileged to work with a wonderful group of people. Thank you to my colleagues, Bahar Aameri, Megan Katsumi, and Torsten Hahmann, for sharing the graduate student experience with me. Finally, I would like to thank my family and friends for their confidence in me, and the values that they have instilled in me. I am extremely grateful for the tolerance that they have demonstrated with me, and I feel so fortunate for their continued support of my academic endeavours.

iii Contents

1 Introduction1

1.1 Ontologies & the Semantic Web...... 2 1.2 Motivations...... 4 1.3 Contributions...... 6 1.4 The Big Picture...... 7

2 Background8

2.1 Usage of First Order and Common Logic Representation...... 8 2.1.1 Common Logic (CL)...... 9 2.1.2 The COmmon Logic Ontology REpository (COLORE)...... 10 2.1.3 Relationships Between Hierarchies...... 12 2.1.4 Verification of Ontologies...... 17 2.1.5 The Process Specification Language (PSL)...... 18 2.2 Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) 20 2.2.1 Assumptions and Simplifications Made to DOLCE...... 20 2.2.2 Overview of Concepts Found in DOLCE...... 27

3 Ontology Decomposition: Verification of DOLCE 31

3.1 Modularizing DOLCE...... 31 3.1.1 Modules from Consistency of DOLCE...... 31 3.1.2 Our Approach to Modularization...... 33

iv 3.1.3 Usage of Bipartite Incidence Structures...... 35

3.1.4 The DOLCE Hierarchy (Hdolce) & Its Modules...... 43

3.2 DOLCE’s Taxonomy (Tdolce taxonomy)...... 44

3.3 DOLCE’s Time Mereology (Tdolce time mereology)...... 45

3.3.1 Axiomatization of Tdolce time mereology ...... 45

3.3.2 Reduction of Tdolce time mereology ...... 49

3.4 DOLCE’s Mereology (Tdolce mereology)...... 51

3.5 A Taxonomy of Lines (Ttaxonomy)...... 51

3.6 Theory of Being Present (Tdolce present)...... 54

3.6.1 Axiomatization of Tdolce present ...... 54

3.6.2 Reduction of Tdolce present ...... 55

3.7 Theory of Temporary Parthood (Tdolce temporary parthood)...... 56

3.7.1 Axiomatization of Tdolce temporary parthood ...... 57

3.7.2 Reduction of Tdolce temporary parthood ...... 57

3.8 Theory of Constitution (Tdolce constitution)...... 62

3.8.1 Axiomatization of Tdolce constitution ...... 62

3.8.2 Reduction of Tdolce constitution ...... 63 3.9 Summary of DOLCE Modules...... 68

4 Ontology Composition: Interpretations Between DOLCE & COLORE 69

4.1 Relationship with PSL and COLORE Theories...... 70 4.2 Temporal Theories in COLORE...... 72

4.2.1 The Timepoints Hierarchy (Htimepoints)...... 73 4.2.2 The Periods Hierarchy (Hperiods)...... 73 4.2.3 The Combined Time Hierarchy (Hcombined time)...... 74

4.2.4 Composing Tinterval with endpoints ...... 77

4.3 Extending Tpsl core ...... 78

4.3.1 Theory of PSL-Core Root (Tpsl core root)...... 78

v 4.3.2 Theory of Mandatory Participation (Tmandatory)...... 79

4.4 The Interval PSL Hierarchy (Hinterval psl)...... 80

4.4.1 Theory of PSL-Core with Intervals (Tinterval psl core)...... 80

4.4.2 Theory of Mandatory Intervals (Tinterval mandatory)...... 82 4.5 Interpretations Between DOLCE and Theories in COLORE...... 82

4.5.1 Interpretations Between Tinterval psl core and Tdolce present ..... 84 ∗ 4.5.2 Interpretations Between Tinterval mandatory and Tdolce participation ... 87 4.6 Insights...... 88

5 Semantic Augmentation: The CIMOSA Process Ontology 89

5.1 Background & Motivation...... 89 5.2 The Computer Integrated Manufacturing Open System Architecture... 92 5.3 Methodology...... 102 5.3.1 Identification of Competency Questions...... 103 5.3.2 Utilizing CIMOSA’s Grammar...... 103 5.3.3 Identifying Keywords to Piece Together Behavioural Rules.... 104 5.3.4 Axiomatizing the Behavioural Rule Set Through Identification of Similar PSL Constructs...... 105 5.4 The Proposed CIMOSA Process Ontology...... 106 5.4.1 Lexicon...... 106 5.4.2 Behavioural Rules for Well-Structured Processes...... 107 5.4.3 Behavioural Rules for Semi-Structured Processes...... 117 5.5 Discussion...... 118 5.5.1 Limitations of the Ontology...... 119 5.5.2 Inability to Test and Verify Axioms for its Intended Semantics.. 119 5.5.3 The Need for Ontology Design Best Practices...... 120 5.6 Challenges & Difficulties Encountered...... 120 5.7 Insights...... 123

vi 6 Ontology Mapping: ServicedAtHome 124

6.1 Background & Motivation...... 125 6.1.1 Hunch Manifest, Inc...... 125 6.1.2 Semantic Integration of Product and Service Data...... 126 6.2 Infrastructure of Mapping Services & Ontologies...... 127 6.3 Methodology...... 128 6.3.1 Acquiring Sample Vendor Product Details...... 130 6.3.2 Developing the Vendor API Ontologies...... 131 6.3.3 Identifying the Concepts to be Mapped...... 135 6.3.4 Preliminary Mappings Between Vendors...... 135 6.3.5 Preliminary Mappings Between HSO and GoodRelations..... 138 6.3.6 Transforming XML Product Data into RDF...... 142 6.3.7 Mapping the Vendor Product Data...... 145 6.4 Product Mappings in RDF and OWL...... 146 6.4.1 Mappings Between HSO and Amazon...... 146 6.4.2 Mappings Between HSO and Sears...... 147 6.4.3 Mappings Between Amazon and Sears...... 147 6.4.4 Mappings Between HSO and GoodRelations...... 148 6.5 Testing the Mappings via SPARQL Queries...... 149 6.5.1 Cheapest Products...... 150 6.5.2 Cheapest Products Based on Keyword...... 150 6.5.3 Average Price of Products Based on Keyword...... 151 6.5.4 Average Price of Products for Both Vendors...... 152 6.5.5 Combination of Product Data with DBPedia Data...... 153 6.5.6 Average Price of Products for Both Vendors Based on Keyword. 155 6.5.7 All Known Product Attributes for a Combined Product Model.. 156 6.6 Discussion...... 157

vii 6.6.1 Limitations of the Vendor Ontologies...... 157 6.6.2 Usage of RDF/XML to Test the Mappings...... 157 6.6.3 The Need for Adoption of Semantic Technologies in e-Commerce. 158 6.6.4 No One General Methodology for Ontology Mapping...... 159 6.6.5 Existing Product Ontologies are Insufficient...... 159 6.7 Insights...... 160

7 Conclusion 162

7.1 Open Issues...... 164 7.2 Future Work...... 165

Bibliography 168

Glossary 176

A Additional Background Information 185

A.1 The PSL Ontology...... 185

A.1.1 Axioms of Tpsl core ...... 185 A.1.2 Core Theories of the PSL Ontology...... 187 A.2 PSL Lexicon...... 187

B Additional DOLCE Information 189

B.1 DOLCE Axioms from WonderWeb...... 189 B.2 Additional DOLCE Axioms...... 192

B.2.1 Axiomatization of Tdolce present ...... 192 ∗

C Additional CIMOSA Information 193

C.1 Axiomatizations of PSL Constructs Used in the CIMOSA Ontology... 193 C.2 Common Logic Version of the CIMOSA Ontology...... 194

viii D Additional HomeServices Information 201

D.1 Sample Item XML Result from Amazon...... 201 D.2 Sample Item XML Result from Sears...... 205 D.3 API Queries for Product Information Retrieval...... 207 D.4 Transforming Raw Vendor Product Data...... 211 D.4.1 Using GRDDL to Transform XHTML/XML into RDF...... 211 D.4.2 Using xsltproc ...... 212 D.5 Using AllegroGraph to Test Product Mappings...... 212 D.5.1 Importing the Data into AllegroGraph...... 213 D.5.2 Using AllegroGraph’s Materializer and Reasoner...... 213 D.6 Results from SPARQL Queries for HSO Mappings...... 214 D.7 Sample GoodRelations Tags in Sears Product Pages...... 218

ix List of Tables

2.1 Basic Categories in DOLCE...... 22 2.2 Summary of concepts found in DOLCE...... 27

5.1 CIMOSA behavioural rules...... 98 5.2 Definition of Terms Found in CIMOSA...... 108 5.3 Lexicon for CIMOSA in first-order logic...... 109 5.4 Comparison between CIMOSA and PSL’s lexicons...... 109

6.1 Excerpt of metadata tags found in Amazon product data...... 133 6.2 Excerpt of metadata tags found in Sears product data...... 134 6.3 Mappings between Amazon and Sears OWL ontologies...... 138 6.4 Mappings between GoodRelations and HomeServices/GIST OWL ontolo- gies...... 142

A.1 Lexicon used in the core theories of the PSL ontology...... 188

D.1 Results of finding the cheapest price of products...... 215 D.2 Results of finding the cheapest price of products based on keyword.... 215 D.3 Results of finding the average price of products based on keyword..... 215 D.4 Results of finding the average price of products and lists them according to manufacturer number...... 215 D.5 Results of finding the average price of products based on keyword for both vendors and lists them according to manufacturer number...... 215

x D.6 Results of finding the combined product model, sorted by manufacturer part number. (Results are truncated due to limited page space.)..... 216 D.7 Results of the federated query. Note that the results are incorrect and that the brandDBPediaURI field is empty...... 217

xi List of Figures

2.1 Classification of DOLCE categories from [51]...... 21

3.1 Structure of DOLCE’s subtheories...... 34 3.2 Relationships between DOLCE modules...... 36 3.3 Mappings between DOLCE and COLORE theories...... 36

3.4 Example of mereological foliation (Tm foliation)...... 38

3.5 Ontologies in Hsubposet...... 40 3.6 Ontologies in Hmereology...... 41 3.7 Ontologies in Hordering...... 42 3.8 Relationships between DOLCE modules with mathematical structures in COLORE...... 43

3.9 Axioms outlining the subsumption constraints of Tdolce taxonomy...... 46

3.10 Axioms outlining the disjointness constraints of Tdolce taxonomy...... 47

3.11 Axioms outlining the disjointness constraints of Tdolce taxonomy...... 48

3.12 Axioms of Tdolce time mereology...... 50

3.13 Axioms of Tdolce mereology...... 52

3.14 Axioms of Tdolce mereology...... 53 3.15 Corresponding taxonomies of DOLCE categories and lines...... 53

3.16 Axiomatization of Ttaxonomy, used in our DOLCE modularization..... 54

3.17 Axioms of Tdolce present...... 55

3.18 Axioms of Tdolce temporary parthood...... 58

xii 3.19 Axioms of Tdolce temporary constitution...... 63

4.1 Relationships between DOLCE modules and theories in COLORE..... 72 4.2 Relationships between theories found in the Combined Time hierarchy,

Hcombined time...... 75

4.3 Axioms found in Tmandatory...... 79 4.4 Relationships between theories found in the PSL hierarchy...... 79

4.5 Axioms of Tinterval psl core...... 81 4.6 Graphical depiction of the overlay(x, y, z) relation...... 81 4.7 Relationships between the Interval PSL, PSL, and Combined Time hier- archies...... 83 4.8 Interpretations between DOLCE modules and theories in COLORE.... 84 4.9 Graphical depiction of the P (x, y) translation definition...... 85 4.10 Graphical depiction of the SUM(z, x, y) translation definition...... 86

5.1 The CIMOSA modelling approach...... 93 5.2 CIMOSA modelling constructs...... 95

6.1 Relationship between the different API technologies and ontologies.... 129 6.2 Relationship between the mappings across the different ontologies..... 146 6.3 The Semantic Web Stack...... 158

A.1 The core theories of the PSL Ontology...... 187

B.1 Axioms of Tdolce present ...... 192 ∗

D.1 Copying queries into Amazon’s Product Advertising API Scratchpad... 208 D.2 Selecting rules for AllegroGraph’s materializer...... 214 D.3 Enabling reasoning in the SPARQL query...... 214

xiii Chapter 1

Introduction

The use of ontologies in knowledge representation has become increasingly popular of over the years. Ontologies are shared conceptualizations that formally define the concepts, relationships, and semantics of a given domain of discourse. As well, ontologies can be described in languages of varying degrees of formality and expressivity. The development of automatic reasoning systems have enabled the community to determine the validity of logical inferences of ontologies by checking the truth of entailments in a given theory or instance of a model. For this reason, we are interested in ontologies defined in the language of first-order logic (FOL) since its expressiveness allows us to define complex concepts and relationships and to verify them with well-defined inference methods and tools. There exist various relationships between ontologies that have been studied exten- sively, and some not as much. In this work, we consider and examine four of these ontology relationships: ontology composition, ontology decomposition, semantic aug- mentation, and ontology mapping. An underlying aspect of the relationships we have chosen to examine is that these relationships have been axiomatically defined in a logic. By examining the similarities and differences between various first-order ontologies, we aim to gain a better understanding of the underlying relationships between ontologies as

1 Chapter 1. Introduction 2 a whole. We briefly introduce the topic of ontologies and, more specifically, describe the four ontology relationships we have chosen to examine. We then discuss the motivations of approach this research problem, outline the major contributions of this work, and provide an overview of the work done in this thesis.

1.1 Ontologies & the Semantic Web

An ontology is simply defined to be ‘an explicit specification of a conceptualization’ [20]. Since domains of discourse can be represented and modelled in different ways, ontolo- gies are known to be a shared conceptualization that allows shareability and reusability within various groups in industry [31]. Despite the various degrees of formality between what one refers to as ‘ontologies’1, they are composed of a vocabulary of terms, and a specification of meaning of the terms. Languages for formal ontologies are closely related to mathematical logic: knowledge is specified as theories in ontologies, in which seman- tics are based on the notion of mathematical interpretations (models of the ontology). By writing axioms in first-order logic, it allows the verification of theories through the use of (semi)automatic theorem provers that read in a computer-interpretable version of the ontology. Without explicit semantics, the inference process needs to be conducted by an engineer, a consultant, or a domain expert. If (semi)automated analysis is not needed, two domain experts will need agree on the verification or validation of a model of the ontology; however, it is often the case such experts are not available, so explicit semantics need to be defined. The primary goal of the Semantic Web is to have a web of data that can be easily processed by machines to allow greater reuse of data across different software applica- tions. This reuse of data leads to greater semantic interoperability, which is the seamless exchange of information between software applications. With the growth of the World

1These include taxonomies, thesauri, data models, and other various representations. Chapter 1. Introduction 3

Wide Web and consequently the Semantic Web, however, there has been an increase in the number of ontologies being created and utilized within the community. This growth is due to the many different ontologies that represent and mean the same thing, which has attributed to the semantic heterogeneity problem within the Semantic Web. Con- sequently, a primary area of research is to examine the various relationships between ontologies of the same, or different, domain. We have chosen to examine four ontology relationships that have been axiomatized in first-order logic:

Ontology Decomposition (Modularization): The extraction of a subset of a • given ontology that captures all of the ontology’s knowledge about a specified set of terms is not a simple task. The ontology modularity community is primarily interested in promoting the greater reuse of ontologies; consequently, modularity is central to reducing the complexity of designing and understanding ontologies, as well as facilitating ontology verification, reasoning, development, maintenance and integration. In this work, we partially decompose the Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) ontology into modules and verify these modules with mathematical theories found in the COmmon Logic Ontology Repository (COLORE).

Ontology Composition: The task of (re)composing existing ontologies, or ontol- • ogy modules, together to form a new ontology arises from the interest of greater reuse of ontologies. Within larger domains of discourse, there is an implicit agree- ment about the terms and concepts defined in individual and independent ontolo- gies. Such terms need to be consistent in interoperable environments and integra- tion scenarios [44, 57]. In this work, we combine mathematical theories with the Process Specification Language (PSL) ontology, both of which are found in COL- ORE, to understand the similarities between the notions of activity participation found in the PSL and DOLCE ontologies. Chapter 1. Introduction 4

Semantic Augmentation: In the context of developing ontologies and provid- • ing additional semantics to ontologies without any concrete definitions or axioms, semantic augmentation links the constructs to be defined with concepts from pre- defined theories and axioms found in other ontologies. By semantically augmenting ontologies together, users are able to fully benefit from the reasoning capabilities of semantic technologies that utilize computer-interpretable ontology formats. In this work, we propose a process ontology for the Computer Integrated Manufacturing Open System Architecture (CIMOSA) framework that utilizes terminology found in the PSL ontology to define CIMOSA constructs and behavioural rules.

Ontology Mapping: With respect to ontology mapping, the research community • is interested in determining whether two contextually equivalent ontologies contain the same, or similar, axioms and descriptions of concepts. We make the following distinction between ontology mapping from ontology composition to avoid con- fusion: the intent of ontology mapping is to make semantic matches between the ontologies and to utilize these matches to aid us in reasoning tasks, whereas ontology composition is intended to aggregate ontologies together with minimal mismatch and to define concepts and relations with vocabularies between both ontologies [44, 42]. In this work, we consider the application of ontology design and ontology mappings in e-commerce.

1.2 Motivations

The primary motivation of this work is to give better insight of axiomatized relationships between ontologies, and to uncover any implicit relationships of which users the ontologies should be aware. Originally, the intent of the thesis was to explore ontology mappings and the various techniques of developing mappings, but upon examining the literature, it was found that there exist many terms used to describe the notion of ‘mapping.’ For Chapter 1. Introduction 5 example, the authors of [42] and [10] survey the state of the art with ontology mapping and make note of the following terms used to describe mapping formalisms and tech- niques in the existing mapping literature: bridge axioms, ontology alignment, ontology articulation, ontology integration, ontology mapping, ontology merging, ontology reconcil- iation, ontology transformation, and ontology translation. Definitions of the terminology used in [50], [10], [65], and [42] can be found in the Glossary on page 175. Since there does not appear to be a clear and community-accepted distinction between the terms used, nor is there one ultimate definition of ontology mapping, we opted to refrain from providing definitive definitions of these terms. However, we made note that there is still something that bridges two ontologies together. Be it translation definitions, mapping axioms, subsumption relationships, or what the authors of [67] call bridge axioms, we were particularly interested in exploring the different relationships that arise between ontologies that may or may not be in the same domain of discourse. Furthermore, our examination of these ontology relationships arose from interests in analyzing how weak and strong ontologies can form relationships with one another. A weak ontology is characterized by the lack of the expressible or characterizable semantics and the ability to express very simple meaning [55, 31]; in contrast, a strong ontology is characterized by its ability to characterize complex semantics in a set of axioms to allow valid inferences and enforce sound semantic constraints through the use of theorem provers [55]. In particular, we examine the relationships between two strong ontologies (DOLCE and PSL), strong and weak ontologies (PSL and CIMOSA, respectively), and two weak ontologies based on raw product data provided by e-commerce vendors. Since there exist more analysis techniques for strong ontologies, such as those described in [29], [43], and [48], we take these techniques into consideration in our work, whereas our analysis of the weaker ontologies will be more ad-hoc in nature due to the lack of methodologies for analyzing weak ontologies. Exploring all of the possible relationships between ontologies was beyond the scope of Chapter 1. Introduction 6 this thesis. Instead, we opted to examine four relationships between ontologies that have been axiomatized in a formal logic. Consequently, we present these four relationships as individual case studies, each of which will be discussed in more detail in their respective chapters:

1. Ontology Decomposition: translation definitions are used in the modularization of the strong DOLCE ontology.

2. Ontology Composition: the combination of strong theories pertaining to geometry, mereology, and time found in COLORE outlines the relationships between the strong DOLCE and PSL ontologies.

3. Ontology Mapping: equivalent concepts between two weak vendor product ontolo- gies are defined through the usage of mappings.

4. Semantic Augmentation: translation definitions are used to define relations in the weak CIMOSA ontology using terminology found in the strong PSL ontology.

1.3 Contributions

This thesis makes several contributions to the ontology and modularity communities. Firstly, we have partially modularized an upper ontology that is used by the community and verified its modules in order to understand the meta-theoretic interactions between the axioms found in these theories. Secondly, the application of mathematical theories in the modularization of DOLCE provides the research community with a better under- standing how the DOLCE ontology can be utilized with mathematical theories. Similarly, the composition of theories from DOLCE and PSL enabled us to formally identify com- mon intuitions between the two ontologies. Furthermore, we develop a process ontology to describe the behavioural rules found in the CIMOSA modelling framework. The de- velopment of this process ontology has identified the need for a general methodology for designing ontologies where semantics are not formally specified in logic. The lack of a methodology has identified additional areas of research for the community to examine, particularly in situations where ontologies need to be developed and evaluated for seman- Chapter 1. Introduction 7 tically weak standards. Finally, we examine an application of ontology mappings in the world of e-commerce and outline the beneficial uses of ontologies in practical applications.

1.4 The Big Picture

This thesis is structured as follows: in Chapter2, we discuss the motivations for this re- search opportunity, describe the background theories used, and outline the methodologies taken; in Chapter3, we outline the techniques used to decompose DOLCE into modules and discuss our findings; in Chapter4, we outline our approach to mapping DOLCE with theories found in COLORE and discuss our findings; in Chapter5, we describe the process ontology developed for CIMOSA and its potential applications within the com- munity; in Chapter6, we discuss the techniques used to map web services together with the use of ontologies and their applications in e-commerce; and finally, in Chapter7, we discuss the insights gained from this thesis, any open issues, and areas of future work. Chapter 2

Background

In this chapter, we introduce the usage of first-order representations of ontologies in this thesis. As well, we introduce the repository environment that contains the theories and ontologies that are mapped to the DOLCE ontology. We explain the choice of focusing on these first-order logic theories and ontologies, which are axiomatized in the Common Logic Interchange Format (CLIF) notation, in relation to their relationships with concepts found in DOLCE. We define the notions of interpretability for comparing theories that use different non-logical lexicons and the translation definitions required to translate axioms from one theory into the language of the other. Then, we describe and outline the modifications made to the DOLCE ontology required for our modularization.

2.1 Usage of First Order and Common Logic Repre-

sentation

In order to capture the semantics of concepts utilized in this work, first-order logic is utilized due its expressive power and usages in the ontologies we have examined. Other ontology languages, such as the Resource Description Framework (RDF) and Web On- tology Language (OWL), have expressive limitations that would have prevented us from

8 Chapter 2. Background 9 developing a computer-interpretable version of DOLCE that remains true to its semantics as defined in [51]. While there exists an OWL version of the DOLCE ontology, known as DOLCE-LITE1, it is grossly simplified with the removal of temporal-indexed relations and inconsistent renaming of relations [52]; the temporal-index relations are vital to the ontology as a whole, so it was more beneficial to utilize a logic with maximal expressivity in this work. Furthermore, our usage of first-order logic in this work aids us in developing a computer-interpretable version of the DOLCE ontology in the Common Logic (CL) and Prover9 syntaxes (with some modifications which are outlined in Section 2.2). The au- thors of [51] only provide the DOLCE ontology in first-order logic sentences with modal operators, and do not provide the ontology in a computer-interpretable format that al- lows users to analyze and verify their axioms. The authors of [48] provided a set of computer-interpretable axioms for their modular consistency proof of DOLCE in the Common Algebraic Specification Language (CASL) syntax; these axioms form the basis of the work in Chapter3, but we have modified and extended them in the Common Logic and Prover9 syntaxes to carry out our modularization of DOLCE and other map- ping tasks. As we will see in later chapters, higher-order logic was not required in our modularization of the DOLCE ontology.

2.1.1 Common Logic (CL)

We utilized a repository environment to store these computer-interpretable ontologies and theories in the Common Logic syntax. Common Logic is a standardized logical language for the specification of first-order ontologies and knowledge bases, and its details can be found in the ISO 24707:2007 document [41]. The author of [34] discusses the flexibility of the CLIF and its ability to support the high-level of expressibility in first-order logic. Consequently, all of the ontologies and theories found in the repository environment are

1DOLCE-LITE can be accessed via http://www.loa.istc.cnr.it/ontologies/DLP_397. owl. Chapter 2. Background 10

written in Common Logic. With this in mind, we are able to examine meta-theoretic relationships between ontologies found in COLORE and, where applicable, prove them based on the first-order notions of interpretability and representation. The soundness and completeness of first-order logic aids us in the verification of theories: anything proven using the axioms of a theory holds for all possible models of that theory. For readability purposes, axioms are written in the traditional first-order logic syntax in this work, and the CLIF versions can be found online in the repository.

2.1.2 The COmmon Logic Ontology REpository (COLORE)

The COmmon Logic Ontology REpository2 is an open repository of first-order ontologies that serves as a test environment for the design, evaluation, and application of these ontologies. The existence of the repository gives the community a common foundation for developing complex ontologies and allows the exploration and examination of stored ontologies in an efficient and directed manner. Ontologies that share a similar domain are explicitly linked in the CLIF files, allowing users to explore a hierarchy composed of the related ontology modules, along with any extensions derived from mapping modules together. All theories within the repository are organized into hierarchies; a detailed discussion of the organization of theories within hierarchies can be found in [29]. Since each module of an ontology represents a different set of ontological commitments, having the repository connect all ontologies that share logical similarities allows greater reuse of these modules; for example, when two ontologies are connected through the repository, they are able to use translation definitions within the repository to share their modules. Thus, as the repository grows, the number of semantic integration possibilities increases as well to enable users to gain a better understanding of what information can be shared between modules along with the various relationships between these modules.

2COLORE can be accessed via http://colore.oor.net. Chapter 2. Background 11

Hierarchy Structure of Ontologies in COLORE

Prior to discussing what it means for a set of theories or ontologies to be in a hierarchy, we adopt the following definitions from [14].

Definition 2.1.1 A first-order theory is a set of first-order sentences that are closed under logical entailment.

Definition 2.1.2 The signature, or the non-logical lexicon, of a first-order theory T is

denoted by Σ(T ). It is the set of all constant symbols, function symbols, and relation symbols that are used in T . The language of T , denoted by (T ), is the set of first-order L formulae that only use the non-logical symbols in the signature Σ(T ).

Definition 2.1.3 Let T1 and T2 be two first-order theories such that Σ(T1) Σ(T2). ⊆ T2 is an extension of T1 iff for any sentence σ (T1), ∈ L

if T1 = σ, then T2 = σ. | |

T2 is a conservative extension of T1 iff for any sentence σ (T1), ∈ L

T2 = σ iff T1 = σ. | |

T2 is a non-conservative extension of T1 iff T2 is an extension of T1 and there exists a

sentence σ Σ(T1) where ∈

T1 = σ and T2 = σ. 6| |

A first-order ontology is a set of first-order sentences (axioms) that characterize a first- order theory, which is the closure of the ontology’s axioms under logical entailment. Two ontologies O1 and O2 that use the same non-logical lexicon Σ have logically equivalent theories if all sentences σ expressed in Σ can be represented as follows:

O1 = σ O2 = σ | ⇔ | Chapter 2. Background 12

With these definitions, we are able to order sets of theories that are expressed in the same signature. We adopt the definition used in [29] to describe the notion of a hierarchy.

Definition 2.1.4 A hierarchy H = , is a partially ordered, finite set of theories hH ≤i = T1,...,Tn, such that: H

1. For all i and j, Σ(Ti) = Σ(Tj),

2. Ti Tj iff Tj is an extension of Ti, ≤

3. Ti < Tj iff Tj is a non-conservative extension of Ti.

All theories in a particular hierarchy share the same set of non-logical symbols, and are ordered by non-conservative extensions, such that the extensions restrict the set of models of which the theory extends. This ordering relation allows us to say that a theory

Ti is stronger than a theory Tj if Ti is a non-conservative extension of Tj. We also adopt the following definition of a root theory from [29]:

Definition 2.1.5 A theory T in a hierarchy is a root theory iff it does not non-conservatively extend any other theory in the same hierarchy.

2.1.3 Relationships Between Hierarchies

An ontology repository like COLORE allows us to examine the network of meta-theoretic relations defined between the theories found in the repository. These relationships allow us to compare the theories easily rather than simply examining the models generated from the axioms. This comparison enables us to determine one theory is stronger, weaker, equivalent to, or inconsistent with another. New theories can also be defined to capture shared, or overlapping, models between two theories. Chapter 2. Background 13

Hierarchies and Conservative Extensions

We adopt the following theorem from [29] to show that a hierarchy H1 is not necessarily

a non-conservative extension of another hierarchy H2, since new theories can always be

added to H2 that are conservatively extended by theories in H1.

Theorem 2.1.1 Suppose T1 and T2 are theories that are in different hierarchies such that Σ(T1) Σ(T2). If T2 is a non-conservative extension of T1, then there exists a ⊂ theory T3 such that:

T2 is a conservative extension of T3, and • T3 is compatible with the hierarchy of T1: Σ(T3) = Σ(T1). •

Interpretability

In order to compare ontologies that are axiomatized in different and disjoint non-logical lexicons, there is a need to translate a theory from one lexicon to the other while pre- serving the original semantics of the relations. The following definitions are adopted and adapted from [14] and [29].

Definition 2.1.6 An interpretation π of a theory T1 with the signature Σ(T1) into a

theory T2 with the signature Σ(T2) is a function on the set of non-logical symbols of

Σ(T1) and formulae in (T1), such that L 1. π assigns to a formula π∀ of (T2), in which at most the variable v1 occurs free, such that ∀ L

T2 = ( v1)π∀ | ∃

2. π assigns to each n-place relation symbol P a formula πP of (T2), in which at most L the variable v1, . . . , vn occur free.

3. For any sentence σ (T1), ∈ L

T1 = σ T2 = π(σ) | ⇒ |

The mapping π is an interpretation of T1 if it preserves the theorems of T1; we say that

“T1 is interpretable in T2.” Chapter 2. Background 14

Definition 2.1.7 An interpretation π of a theory T1 into a theory T2 is a faithful interpretation, if and only if, for any sentence σ (T1), ∈ L

T1 = σ T2 = π(σ) 6| ⇒ 6|

Thus, the mapping π is a faithful interpretation of T1 if it preserves satisfiability with respect to T1. We will also refer to this by saying that “T1 is faithfully interpretable in

T2.” With this in mind, the definition of definable equivalence is also adopted from [29] to generalize the notion of logical equivalence between theories that do not have the same signature.

Definition 2.1.8 Two theories, T1 and T2, are definably equivalent iff T1 is faithfully

interpretable in T2, and T2 is faithfully interpretable in T1.

An example of definably equivalent theories can be found in temporal ontologies, such as between the mathematical theories of timepoints and linear orderings axiomatized in [35]. In contrast, the theory of partial orderings is interpretable in the theory of timepoints, but these two theories are not definably equivalent because the theory of timepoints is not interpretable in the theory of partial orderings. Thus, we can say that faithful interpretations are a generalization of the notion of conservative extensions, so we can generalize the following [29]:

Theorem 2.1.2 T1 is faithfully interpretable in T2 iff there is theory T3 such that T1 is

definably equivalent to T3 and T2 is a conservative extension of T3.

The proof for this theorem can be found in [29].

Reducibility of Theories

Another approach to modularity is based on the relationship of reducibility, in which one ontology is definably equivalent to the union of existing modules found in different hierarchies[28, 29]. We adopt the following definition of reducibility from [29]. Chapter 2. Background 15

Definition 2.1.9 A theory, T , is reducible to a set of theories T1, ..., Tn iff:

T faithfully interprets each theory Ti, and •

T1 ... Tn faithfully interprets T . • ∪ ∪

In the remainder of this work, we refer to the set of theories T1, ..., Tn as the “reduction of T ” in COLORE. From this definition, we can see that two definably equivalent theories are reducible to each other. A trivial example can be found in the Combined Time hierarchy of COLORE, where the theory of timepoints is reducible to the theory of linear orderings, and vice versa. A non-trivial example of reducibility can be seen with the

PSL-Core theory, Tpsl core, found in the PSL Ontology (described in Section 2.1.5). In

[28], the authors show that Tpsl core is reducible to Tlinear, Tpartition, and Tgraph incidence. This example illustrates how reducibility leads to the decomposition of a theory that is treated as a module within a larger ontology [28], thus we adopt the following from [29]:

Theorem 2.1.3 Let T1, ..., Tn be a set of theories such that Σ(Ti) Σ(Tj) = for all ∩ ∅ i j, j n, i = j. A theory T is reducible to T1, ..., Tn iff T is definably equivalent to ≤ ≤ 6 T1 ... Tn. ∪ ∪

The proof for this theorem can be found in [29]. From this theorem, the following corollary is also defined:

Corollary 2.1.4 If T1 is definably equivalent to T2, then T1 is reducible to T2.

Translation Definitions

In order to map concepts between ontologies, we specify the semantic mappings in the form of translation definitions; this definition is adopted from [29] and [14].

Definition 2.1.10 Let T0 be a theory with the signature Σ(T0) and T1 be a theory with

the signature Σ(T1), such that Σ(T0) Σ(T1) = . If there is an interpretation of ∩ ∅ Chapter 2. Background 16

T0 in T1, then there exists a set of sentences that axiomatizes the mapping, called a

translation definition, in the language of L0 L1 of the form: ∪

( x¯)pi(¯x) Φ¯x ∀ ≡

where pi(¯x) is a relation symbol in L0 and (Φ¯x) is a formula in L1 whose only free variables are x¯.

From [60], translation definitions can be considered to be an axiomatization of the in- terpretation of T0 into T1, where they conservatively extend T0 and definitionally extend

T1.

Proving Relationships Between Theories

We utilized a semi-automated procedure to verify theories with the aid of the Prover9 and Mace4 software applications3. Prover9 is an automated theorem prover for first- order logic that uses resolution to prove goal sentences which are entailed by the inputted theory; Mace4 is a finite model generator that complements Prover9 since it searches for countermodels of the inputted goal. To prove relationships between two theories found in different hierarchies, we adopt the methodology used in [29] to determine the definable equivalence of theories. Suppose

∆12 and ∆21 are the translations for T1 into T2 and T2 into T1, respectively. To verify that two theories, T1 and T2, are definably equivalent, we carry out the following reasoning problems:

1. T1 T2 ∆12 is consistent, ∪ ∪

2. T1 ∆12 = T2, ∪ |

3. T1 T2 ∆21 is consistent, and ∪ ∪

4. T2 ∆21 = T1. ∪ | 3Prover9 and Mace4 are available via http://www.cs.unm.edu/˜mccune/mace4/. Chapter 2. Background 17

If all four reasoning problems produce successful results, then it means that theories T1 and T2 are definably equivalent. This means that T1 and T2 are alternative axiomati- zations of the same set of models. If steps 1 or 3 fail, then the translation definitions between the theories are inconsistent and the two theories have two disjoint sets of mod- els; this means that they are not translatable into one another. If step 2 fails, then it indicates that T1 may be weaker than T2; likewise, if step 4 fails, then T2 may be weaker than T1. For these ‘weaker’ theory scenarios, one theory is strictly weaker than the other if it is possible to find a definably equivalent theory of the stronger theory in the core hierarchy of the weaker theory, and show that it non-conservatively extends the weaker theory.

2.1.4 Verification of Ontologies

To verify an ontology, we apply model-theoretic notions in our analysis of the DOLCE ontology. We characterize the semantics of an ontology as a set of intended structures4. We specify these structures with well-understood mathematical theories to determine whether the axiomatization of an ontology matches its intended models; these theories include partial orderings, lattices, incidence structures, geometries, and algebra [23, 28]. If an ontology’s axiomatization contains unintended models, then it is possible to find sentences that are entailed by the intended models, but these sentences are not provable from the axioms of the ontology. Such models provide barriers to semantic interoperabil- ity between software systems and may prevent the entailment of sentences [23, 28]. By verifying an ontology, we would like to characterize its models up to isomorphism to determine whether or not these models are equivalent to the intended structures of the ontology [23]. To do this, we utilize the mathematical notion of representation theorems, where we prove that every intended structure is a model of the ontology and that every model of the ontology is elementary equivalent to some intended structure. In this work,

4Adopted from [23] for the ontology, an intended structure is a set of structures that characterizes the semantics of an ontology’s terminology. Chapter 2. Background 18

we leverage work done by mathematicians for theories such as orderings, lattices, algebra, and incidence structures to verify the ontologies of domains such as time, process and mereology.

2.1.5 The Process Specification Language (PSL)

The Process Specification Language (PSL) is designed to facilitate the correct and com- plete exchange of process information among manufacturing systems [31]. With the in- creasing use of information technology in manufacturing systems, it has been increasingly important to integrate different software applications together to ensure interoperability among them. However, these applications may use the same or different terminology to associate different semantics with the terms in the domain. This is still evident if two ap- plications utilize the same terminology - they may associate different semantics with the terms. This clash of meaning between terms prevents seamless exchange of information among software applications [31]. Consequently, PSL was designed to “create a process representation that is common to all manufacturing ap- plications, generic enough to be decoupled from any given application and robust enough to represent the necessary process information for any given application” [13].

PSL is meant to be a neutral, interchange language that integrates multiple process- related applications throughout the manufacturing life cycle [12]; typically, point-to-point translation programs are created to facilitate communication between applications, but with the increasing number of such programs, it has become very difficult for software developers to provide translators between different pairs of applications [31]. The PSL Ontology is organized into PSL-Core and a partially ordered set of exten- sions. All axioms are first-order sentences written in Common Logic and can be found in COLORE5. Within PSL, two types of extensions exist: core theories and definitional extensions. Core theories introduce and axiomatize new relations and functions that 5http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_core/ psl_core.clif The first-order logic version of the ontology is also included in Appendix A.1.1. Chapter 2. Background 19 are primitive, whereas definitional extensions consist of conservative definitions that use the terminology of the core theories, meaning that they add no new expressive power to PSL-Core. The PSL ontology also includes a set of extensions that introduce new terminology. Any extension of PSL can axiomatize concepts that are not explicitly spec- ified in PSL-Core. All core theories within the PSL ontology are consistent extensions of

PSL-Core (Tpsl core). Appendices A.1.2 and A.2 contain a depiction of the relationships between these core theories, as well as list the key terms in the lexicon of the core theo- ries of the PSL ontology. Within Tpsl core, the following basic ontological distinctions are made (adapted from [22]):

Activities: a repeatable pattern of behaviour that may have multiple occurrences, • or may never occur.

Activity Occurrences: corresponds to a concrete instantiation of a unique activity. • Activity occurrences are not instances of activities, since activities are not classes within the PSL ontology.

Time: each activity occurrence is associated with unique timepoints that mark • the beginning and end of the occurrence. The set of timepoints is linearly ordered, forwards into the future and backwards into the past; this linear ordering is captured in the PSL Ontology with the before relation.

Objects: those elements that are not activities, occurrences, or timepoints. • State and Change: process ontologies are used to represent dynamic behaviour • in the world to allow software systems to make predictions about the future and explanations with the past. PSL-Core captures basic intuitions about state and its relationship to activities with fluents which are properties in the domain that can change. A fluent is changed by the occurrence of activities, and a fluent can only be changed by the occurrence of activities.

Since the PSL ontology contains axioms that have been well-defined and standardized in ISO 18629-1:2004, it was appropriate to utilize this ontology to examine whether it could be mapped with concepts found in the Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE), which is described in the next section. Chapter 2. Background 20

2.2 Descriptive Ontology for Linguistic and Cogni-

tive Engineering (DOLCE)

The Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) is a foun- dational ontology of particulars6 that captures ontological categories found in natural language and human common sense [51]. It is the first module found in the WonderWeb Foundational Ontologies Library7 (WFOL). There is a cognitive bias in how DOLCE captures these categories since they are considered to be ‘cognitive artifacts’ that are de- rived from human perception, cultural imprints, and social conventions; these categories are graphically shown in Figure 2.1, and listed in Table 2.1. DOLCE is based on the distinction between endurants and perdurants. Endurants are continuants that are perceived at any given point in time, whereas perdurants are occurrents that are partially present at any given point in time. Thus, endurants and perdurants in DOLCE are characterized by whether or not they can exhibit change in time. Endurants are considered to genuinely change in time - in the sense that the endurant, as a whole, can have incompatible properties at different times. In contrast, perdurants cannot change in this sense, since none of their parts keeps its identity in time. We do not give an extensive discussion on the metaphysical properties of these concepts, and direct the reader to [51] for a better understanding of the authors’ design choices in developing DOLCE.

2.2.1 Assumptions and Simplifications Made to DOLCE

In our work with DOLCE, we have had to make assumptions and simplifications in order to compare our modularization techniques with the work done in [48]. We outline these

6The authors of [51] use this to identify that the ontology’s domain of discourse is restricted to these particulars, meaning it is an ontology of instances, rather than an ontology of universals or metaprop- erties. 7The WonderWeb Foundational Ontologies Library can be accessed via http://wonderweb. semanticweb.org/deliverables/D17.shtml. Chapter 2. Background 21

Figure 2.1: Classification of DOLCE categories from [51]. Chapter 2. Background 22

Table 2.1: Basic Categories in DOLCE.

Abbreviation Category AB Abstract ACC Accomplishment ACH Achievement APO Agentive Physical Object AQ Abstract Quality AR Abstract Region AS Arbitrary Sum ASO Agentive Social Object ED Endurant EV Event F Feature M Amount of Matter MOB Mental Object NAPO Non-agentive Physical Object NASO Non-agentive Social Object NPED Non-physical Endurant NPOB Non-physical Object PD Perdurant, Occurrence PED Physical Endurant POB Physical Object PQ Physical Quality PR Physical Region PRO Process PT Particular Q Quality R Region S Space Region SAG Social Agent SC Society SL Spatial Location SOB Social Object ST State STV Stative T Time Interval TL Temporal Location TQ Temporal Quality TR Temporal Region Chapter 2. Background 23 assumptions and simplifications in the subsequent sections that follow.

Removal of Modal Logic Operators

Similar to [48], we have ignored all modal logic operators found in the DOLCE axioms due to difficulties in representing modality in Common Logic and in verifying axioms in the Prover9 syntax. For axioms that include the modal logic, we simply stripped off the modal operators; we demonstrate this with the original definition of specific constant dependence (Dd69 in [51]):

SD(x, y) 2( t(PRE(x, t)) t(PRE(x, t) PRE(y, t))) , ∃ ∧ ∀ ⊃

becomes

SD(x, y) ( t(PRE(x, t)) t(PRE(x, t) PRE(y, t))) , ∃ ∧ ∀ ⊃

Thus, in this work, all modal logic operators (2 for necessarily and 3 for possibly) have been removed in any references of the schematic axioms that are utilized in our modularization. These include the following axioms found in [51]: Dd1, Dd2, Dd3, Dd4, Dd7, Dd10, Dd13, Dd56, Dd57, Dd58, Dd59, Dd60, Dd61, Dd62, Dd69, Dd70, Dd71, Dd78, Dd79, Dd80, Dd81, Dd82, Dd83, Dd84, Dd85, Dd86, Dd96, Dd97, and Dd98.

Weakening Mereological Sum and ‘Fusion’ Axioms

Ad9 and Ad15 in [51] are weakened assuming only the existence of binary sum and binary difference, respectively, as specified by the authors of [48] and in their CASL specification of DOLCE in many-sorted logic document8. Consequently, the definition for mereological sum (Dd19 in [51]) is weakened into two relations Sum(z, x, y) and Dif(z, x, y) as follows:

x σxφ(x) ιz y (O(y, z) w (φ(w) O(y, w))) ∀ ≡ ∀ ≡ ∃ ∧ 8This DOLCE-CASL specification document can be accessed via: http://aaai11dolce. tripod.com/dolce-s-specification-in-many-sorted-first-order-logic.html. Chapter 2. Background 24

becomes

Sum(z, x, y) ( x y w z (O(w, z) (O(w, x) O(w, y)))) ≡ ∀ ∀ ∀ ∀ ≡ ∨

Dif(z, x, y) ( x y w z P (w, z) (P (w, x) O(w, y))) ≡ ∀ ∀ ∀ ∀ ≡ ∧ ¬

Similarly, the definition for mereological sum of temporal properties (Dd27 in [51]) is weakened as shown below.

x σtexφ(x) ιz y t (O(y, z, t) w (φ(w) O(y, w, t))) ∀ ≡ ∀ ∀ ≡ ∃ ∧

becomes

tSum(z, x, y) ( x y w z (O(w, z, t) (O(w, x, t) O(w, y, t)))) ≡ ∀ ∀ ∀ ∀ ≡ ∨

tDif(z, x, y) ( x y w z P (w, z, t) (P (w, x, t) O(w, y, t))) ≡ ∀ ∀ ∀ ∀ ≡ ∧ ¬

These two rewritten axioms only apply to the relations that are all of the same type of property (e.g., for all endurants); in the DOLCE-CASL specification used in [48], the binary sum and binary difference axioms apply to sorts of the same type. As well, the authors of [48] include additional axioms to the DOLCE specification for extensionality and existence of binary difference, existence of the sum, parts of the sum, and proper parts of the sum:

x y P (x, y) z (Dif(z, x, y)) ∀ ∀ ¬ ⊃ ∃

x y P (x, y) z (Sum(z, x, y) ∀ ∀ ¬ ⊃ ∃

x y z Sum(z, x, y) P (x, z) P (y, z) ∀ ∀ ∀ ⊃ ∧

x y z P (x, y) Sum(z, x, y) PP (y, z) ∀ ∀ ∀ ¬ ∧ ⊃ Chapter 2. Background 25

Similarly, for temporal binary sums and differences, the existence of the sum and exten- sionality (and existence of the difference) are given as follows:

x y t t1 t2 z tSum(z, x, y) ∀ ∀ ∀ ∀ ∀ ∃

x y ( t P (x, y, t)) z (tDif(z, x, y)) ∀ ∀ ∀ ¬ ⊃ ∃

x y z t P RE(x, t) tSum(z, x, y) P (x, z, t) ¬∀ ∀ ∀ ∀ ∧ ⊃

All of the above additions have also been included in the Common Logic axioms used in this work.

Treating Being Present as Primitive

The relation PRE(x, t) is assumed to be a primitive relation due to the fusion operators found in the definitional axioms for quality and quales (refer to Axioms Dd28 to Dd39 in [51]). Similar to what the authors of [48] have done, we have not expanded out the definitions of being present to include the fusion operator. The spatial inclusion relation is not defined, nor used, in [48], so we have also decided not to include this in our work. Thus, axioms Ad19, Ad28, and Ad68 are not included in our Common Logic version of DOLCE.

Exclusion of Quality, Quales, and Dependence in DOLCE

We note here that this work partially modularizes the DOLCE ontology. Due to time constraints and problems with how the dependence axioms in DOLCE interact with each other, we opted to partially decompose the DOLCE ontology. For example, the interplay between the DOLCE categories in the mutual specific constant dependence axiom MSD(T Q, P D)(Ad67 in [51]) causes issues when we attempt to verify this module of DOLCE; from the definitional axioms, this axiom becomes the conjunction of two specific constant dependence axioms: MSD(T Q, P D) SD(T Q, P D) SD(PD,TQ). ≡ ∧ Chapter 2. Background 26

The definition of specific constant dependence itself is a more complex axiom that requires further expansion:

SD(φ, ψ) DJ(φ, ψ) ( x (φ(x) ( y (ψ(y) SD(x, y))))) ≡ ∧ ∀ ⊃ ∃ ∧

Thus, we do not include axioms Ad67 to Ad74 from [51] in our work. In DOLCE, qualities are considered to be basic entities that can be perceived or measured. These include shapes, colors, sizes, sounds, smells, as well as weights, lengths, and electrical charges [51]. While the term ‘quality’ is often synonymous with the term ‘property,’ this is not the case in DOLCE: qualities are considered to be particulars, and properties are universals [51]. Every entity, including qualities themselves, comes with certain qualities, which exist as long as the entity exists. Furthermore, DOLCE makes the distinction between a quality (such as the colour of a specific rose) and a quale, its ‘value’ (a particular shade of red) [51]. We do not go into more detail about the distinctions between qualities and quales, and direct the reader to [51], [19], and [9] for additional information about trope theory, from which these distinctions are based. Similar to dependence, the axioms that involve quality, and temporal and spatial quales9 are complex and involve many manual substitutions to arrive at the expanded forms of the axioms. Due to the complexity of these definitions and the semantic inaccuracy of simply declaring these dependence relations as primitive, we decided to examine axioms that did not involve nested and complicated substitutions. Thus, we only present six modules of the DOLCE ontology and the remainder of the ontology will be decomposed in future work discussed in Section 7.2. 9The quality, and temporal and spatial quales are axioms Ad38 to Ad51, and Ad52 to Ad66 in [51], respectively. Chapter 2. Background 27

2.2.2 Overview of Concepts Found in DOLCE

Here we discuss the major concepts found in the ontology that are examined in our partial modularization, and summarize these general concepts in Table 2.2. We also note that the original DOLCE axioms for these concepts can be found in Appendix B.1.

Table 2.2: Summary of concepts found in DOLCE.

DOLCE Concept Description “x is present at t” Being Present PRE(x, t) “x constitutes y during t” Constitution K(x, y, t) (ED(x) PD(x)) (ED(y) PD(y)) T (t) ⊃ ∨“x is part∧ of y” ∨ ∧ Parthood P (x, y) (AB(x) PD(x)) (AB(y) PD(y)) ⊃“x participates∨ in y∧ during t”∨ Participation PC(x, y, t) (ED(x) PD(y) T (t)) “x is⊃ part of y∧ during t”∧ Temporary Parthood tP (x, y, t) (ED(x) ED(y) T (t)) ⊃ ∧ ∧

Endurants and Perdurants

As we have mentioned earlier, DOLCE is based on the distinction between enduring and perduring entities: endurants ED(x) and perdurants PD(x), respectively. In philosophy, these entities are also referred to as continuants and occurrents, where the fundamental difference between the two is related to their behaviour in time [51]. Endurants are wholly present at any time, whereas perdurants extend in time by accumulating different temporal parts, so they are only partially present [51]. Endurants are entities that can be observed and perceived as a complete concept, regardless of a given snapshot of time. Material objects are classified as endurants; for example, apples and books are still wholly present when time is frozen. In contrast, perdurants are entities for which only a part exists if we look at them at any given snapshot in time. When time is frozen, we can only observe and perceive a part of the perdurant. For example, if we take the process of ‘running’ and freeze time, we only see Chapter 2. Background 28

a part of the running action; without any prior knowledge of the process, one may not be able to determine whether the actual process at that given snapshot in time is a process of running.

Parthood and Temporary Parthood

The distinction between endurants and perdurants also introduces two kinds of parthood relations in DOLCE: atemporal and time-indexed parthood. Atemporal parthood is used for entities which do not properly change in time, such as occurrences and abstracts [51]. On the other hand, time-indexed parthood holds for endurants since it is necessary to know when a specific parthood relationship holds [51]. Additionally, with time-indexed parthood, two notions are defined in [51]:

1. An endurant is mereologically constant iff all its parts remains the same during its life. For example, material objects are mereologically variable because they can lose or gain parts.

2. An endurant is mereologically invariant iff they remain the same across all possible worlds. For example, amounts of matter are mereologically invariant since all of their parts are essential parts.

Being Present

In DOLCE, temporal existence is modelled by the PRE(x, t) relation, which is read as “x is present at time t.” The authors of [51] and [6] note that the notion of time can be punctual or extended, and can adopt different structures on them, such as discrete or continuous time, and linear or branching time. As well, there are different ways of being in time: existing in time versus occurring in time, or being wholly present versus being partially present (recall the distinction between endurants and perdurants).

Constitution

Constitution is a widely debated concept in philosophy. Some philosophers insist that constitution is identity since distinct material objects cannot occupy the same place at Chapter 2. Background 29

the same time; others, however, argue that constitution is not identity since, for example, a statue and the clay used to make the statue differ in various contexts. In this work, we adopt the definition that constitution is not parthood to be consistent with the views presented in [51]. DOLCE adopts a multiplicative approach in describing the concept of constitution, where different entities can be co-located in the same space-time since entities are given incompatible essential properties [51]. An example described in [51] is that a vase is constituted by an amount of clay, but the vase itself is not an amount of clay. There are certain properties that a particular amount of clay has when it was shaped by the vase-master which are considered as essential for the emergence of a new entity. In language and cognition, this new entity is referred to as a genuinely different thing: for instance, we say that a vase has a handle, but not that a piece of clay has a handle.

Participation

While we do not modularize axioms pertaining to participation in DOLCE, we briefly introduce the notion of participation here since it will be discussed in Chapter4. In the context of DOLCE, the authors of [51] indicate that there are endurants involved in an occurrence, so the notion of participation is not considered parthood. In DOLCE, participation is time-indexed in order to account for the varieties of participation in time, such as temporary participation and constant participation. In DOLCE, PC(x, y, t) stands for “the object x participates in an event y at time t.” We note that additional participation axioms have been proposed by the authors of [6], which form the basis of what they call “DOLCE-CORE”. It is an ontology that is limited to entities that exist in time, referred to as ‘temporal particulars’ in [6]. The primary difference between DOLCE and DOLCE-CORE is that the latter adopts a con- textual perspective by introducing regions and spaces (part of the abstract AB category in Figure 2.1) as temporal entities that are created, adopted, and abandoned [6]. Simi- Chapter 2. Background 30

lar to DOLCE in [51], DOLCE-CORE partitions temporal-particulars PT into six basic categories: objects O(x), events E(x), individual qualities Q(x), regions R(x), concepts C(x), and arbitrary sums AS(x). The original DOLCE categories for endurants ED(x) and perdurants PD(x) are renamed objects O(x) and events E(x), respectively. Further-

more, individual qualities in DOLCE-CORE are partitioned into quality kinds Qi which

are associated to a region in one or more spaces Sij. Due to these modifications of the original DOLCE axioms and slight change in DOLCE constructs, we do not incorporate any of the DOLCE-CORE axioms in our work. Chapter 3

Ontology Decomposition: Verification of DOLCE

In this chapter, we outline and discuss our approach to modularizing the DOLCE ontol- ogy, as well as describe the axioms found in each of the generated modules.

3.1 Modularizing DOLCE

In order to verify the axioms found in DOLCE, we applied the modularization techniques presented in [29] in order to determine whether DOLCE is decomposable and consistent. As a basis for comparison, we examined whether our modules are the same as, or sim- ilar to, the modules presented in [48], and noted the differences in both approaches to decomposing DOLCE.

3.1.1 Modules from Consistency of DOLCE

In [48], the authors present a novel approach at establishing the consistency of DOLCE. They proposed a methodology that utilizes the Heterogeneous Tool Set (HETS)1 to

1HETS is available via http://www.informatik.uni-bremen.de/agbkb/forschung/ formal_methods/CoFI/hets/index_e.htm.

31 Chapter 3. Verification of DOLCE 32 develop an architectural specification for DOLCE that is used to produce relative consis- tency proofs based on conservativity triangles. In HETS, an architectural specification is essentially a software specification that decomposes a large theory into smaller subtasks, which includes the construction of models for these small theories, proving the conser- vativity of theory extensions, and determining whether the constructed theories can be amalgamated together [48]. Relative consistency proofs are used by HETS to provide theory interpretations into another theory that is known or assumed to be consistent. HETS visualizes these relationships between smaller theories via development graphs by denoting the dependencies between the theories. The approach presented in [48] constructed a global model for DOLCE that is built from smaller models of subtheories together with amalgamability properties between such models. The authors hand-crafted an architectural specification of DOLCE which reflects the way models of the theory can be built, and utilized HETS to automatically verify the amalgamability conditions and produce series of relative consistency proofs. The authors of [48] note that the axioms in the dependence theory of DOLCE in- troduced complications in their first modularization attempt since subtle dependencies between parts of DOLCE’s taxonomy were involved. Consequently, they restructured their architectural specification for DOLCE to utilize DOLCE’s temporal mereology in a bottom-up manner. While we do not modularize this theory of dependence in this work, we do make note of how the dependence axioms interact with the taxonomy in future work. As a result of these changes, the structure of HETS’ subtheories as found in [48] is graphically presented in Figure 3.1. The end result consisted of thirty eight units within the architectural specification and eighteen amalgamations, allowing the generation of various finite models for DOLCE[48]. Their architectural specification can be accessed via the authors’ anonymous Association for the Advancement of Artificial Intelligence (AAAI) 2011 submission2; alternatively, the authors’ axioms in the Thousands of Prob-

2http://aaai11dolce.tripod.com/architectural-specification.html Chapter 3. Verification of DOLCE 33

lems for Theorem Provers (TPTP) syntax can be accessed in COLORE in the DOLCE hierarchy3. In [48], there is a lack of discussion of what each DOLCE module contains, along with which ovals in Figure 3.1 are modules of DOLCE since there are also ovals that represent theories that are external to the ontology. For example, there are individual ovals depict- ing Mereology, Mereology and TemporalPart, and Temporary Parthood; we are unsure of the distinction between these modules, and whether or not the Temporary Parthood module contains similar axioms found in Mereology and Mereology and TemporalPart since the only common imported module between them is the Time Mereology mod- ule. This unclear distinction between modules can also be seen in the ovals containing Being Present and Binary Present; we are unsure as to why this refinement was made in their modularization. Our modularization, on the other hand, is much more succinct and clear, since we do not introduce any external theories in the decomposition process.

3.1.2 Our Approach to Modularization

In contrast to the work done in [48], we do not utilize HETS to produce a semi-automatic modularization of DOLCE. Instead, we opted to decompose DOLCE manually using the techniques from [29], as well as verify these modules with Prover9 by mapping them with pre-existing mathematical theories found in COLORE. We were interested in determining if the sets of models of two differently axiomatized ontologies are equivalent. While it is possible to define the CLIF theories as CASL specifications in HETS, a repository environment like COLORE is better-suited for managing varied ontologies and storing any meta-theoretic relationships between these stored theories. HETS is a tool focused more on modularizing a single theory instead of a repository that can manage a large number of varied ontologies and allow users to examine various relationships between 3http://colore.googlecode.com/svn/trunk/ontologies/dolce/dolce.tptp Chapter 3. Verification of DOLCE 34

Figure 3.1: Structure of DOLCE’s subtheories in [48]. Chapter 3. Verification of DOLCE 35

these theories. The current framework for our modularization is shown in Figure 3.2 below. At the

very bottom of the diagram is the DOLCE taxonomy module, Tdolce taxonomy, which con- sists of the categorization of the constructs found in DOLCE. The DOLCE mereology

and time mereology modules, Tdolce mereology and Tdolce time mereology, import the axioms

of Tdolce taxonomy, as denoted by the solid arrows in the figure. As well, Tdolce mereology

imports Tdolce time mereology. We then see that the DOLCE present module, Tdolce present,

imports all of the axioms in Tdolce time mereology, so Tdolce taxonomy is included as well. Like- wise, the DOLCE dependence, participation, and temporary parthood modules4 import

Tdolce present and all of the axioms contained within. Finally, the DOLCE constitution

module, Tdolce constitution, imports all of the axioms in Tdolce temporary parthood. To verify the DOLCE theories, we map them with existing theories found in COLORE. Figure 3.3 illustrates the mappings between the DOLCE theories and COLORE theories. Each of these verification tasks are discussed in their respective sections.

3.1.3 Usage of Bipartite Incidence Structures

In our partial modularization of DOLCE, we utilized bipartite incidence structures found in mathematical theories of COLORE. Bipartite incidence structures are a generalization of geometries: there are two disjoint sets of points and lines, and the incidence relation, in(x, y), specifies the set of points that are incident with a line. We noticed that the constraints on points and lines in geometry were similar to constraints found in the DOLCE constructs, thus we utilized these bipartite incidence structures to assist us with verifying DOLCE. We briefly describe each of these structures below and direct the reader to [24], [25], and [26] for more detailed reading about these structures.

4 Denoted as Tdolce dependence, Tdolce participation, and Tdolce temporary parthood, respectively. Chapter 3. Verification of DOLCE 36

dolce constitution

dolce temporary parthood dolce participation

dolce dependence dolce present

dolce mereology dolce time mereology

dolce taxonomy

DOLCE Hierarchy Figure 3.2: Relationships between DOLCE modules. Solid arrows denote conservative extensions, dashed arrows denote non-conservative extensions, and dashed boxes indicate individual hierarchies.

dolce constitution ideal cem lower reflect down foliation dolce temporary parthood ∪ ideal cem downward m foliation dolce present ∪ ideal cem wmg dolce∪ time mereology ∪ ∪

dolce temporary parthood ideal cem downward m foliation dolce present ∪ ideal cem wmg dolce time mereology ∪ ∪

dolce present dolce time mereology ideal cem wmg ∪

dolce time mereology cem mereology Figure 3.3: Mappings between DOLCE and COLORE theories. Solid arrows denote conservative extensions and solid lines indicate equivalence. Chapter 3. Verification of DOLCE 37

Mereological Geometries, Bundles & Foliations

In our reduction, we utilized structures from the mereological geometry, mereological bundle, and mereological foliations hierarchies:

A mereological geometry 5 is the amalgamation of a bipartite incidence structure • and a mereology that is specified on sets of collinear points (the points that are all incident with the same line). Sets of collinear points need to satisfy axioms for a given mereology, and there may be a global mereology on a set of all points, regardless of collinearity.

In a mereological bundle6, we find a generalization of the part(x, y) relation from • mereology by introducing a ternary relation tpart(x, y, t) that specifies a relativized parthood relation on sets of lines that are coincident with the same point. In mere- ological bundles, a quasiorder is specified on the set of lines that are incident with a point; a mereology is not specified on sets of intersecting lines due to the notion of temporary parthood. In the philosophical literature, the relation for temporary parthood is not considered to be antisymmetric, in contrast to the parthood rela- tion in a mereology. Due to this, mereological bundles contain quasiorderings on sets of intersecting lines.

Mereological foliations7 are simply an amalgamation of mereological geometries • and mereological bundles. A mereology is specified on each set of collinear points and mereological bundle is specified on each set of intersecting lines. Figure 3.4 depicts a structure Mm foliation. Figure 3.4(a) shows the mereology within the mereological geometry,M ∈ and Figure 3.4(b) shows the incidence structure. Note that this is the same incidence structure as the one in the mereological bundle. Figure 3.4(c) shows the mereological bundle: in particular, the quasiorder that is specified on the set of lines in N(pi) for each point pi.

Incidence Bundles & Foliations

Similarly, we also utilize incidence bundles and incidence foliations in our reduction:

With incidence bundles8, an incidence structure is specified on the set of planes • and lines that are incident with a point 5http://code.google.com/p/colore/source/browse/trunk/ontologies/ mereological_geometry/ 6http://code.google.com/p/colore/source/browse/trunk/ontologies/ mereological_bundle/ 7http://code.google.com/p/colore/source/browse/trunk/ontologies/ mereological_foliation/ 8http://code.google.com/p/colore/source/browse/trunk/ontologies/ incidence_bundle Chapter 3. Verification of DOLCE 38

t1 t4 l1 l2 l3

t2 t3 t5 t6 t1 t2 t3 t4 t5 t6

(a) (b)

l2

l1 l3

l1 l1 l3 l3

l2 l2 (c)

Figure 3.4: Example of mereological foliation (Tm foliation).

An incidence foliation9 is an amalgamation of a mereological geometry and an • incidence bundle: a mereology is specified on each set of collinear points and an incidence bundle is specified on each set of coincident lines and planes.

Subposet Bundles & Foliations

In addition to the mereological and incidence structures outlined above, we also utilize structures found in the subposet hierarchy10, Hsubposet, in COLORE. Each ontology in this hierarchy is an extension of an ontology from the Mereology Hierarchy, Hmereology, and an ontology from the Ordering Hierarchy, Hordering. The ontologies shown in Figure

subposet 3.5 form the basis for H . The root ontology Tsubposet root is the union of Tm mereology

and Tpartial ordering, and is a conservative extension of each of these ontologies. Thus,

each model of Tsubposet root (and hence each model of any ontology in the hierarchy) is the

9http://code.google.com/p/colore/source/browse/trunk/ontologies/ incidence_foliation 10http://code.google.com/p/colore/source/browse/trunk/ontologies/subposet Chapter 3. Verification of DOLCE 39

amalgamation of a mereology substructure and a partial ordering substructure. The ontologies shown in Figure 3.5 contain additional axioms that constrain how the

mereology is related to the partial ordering. In models of Tsubposet, the mereology is a subordering of the partial ordering. Tideal strengthens this condition by requiring that the mereology is a subordering of the partial ordering which forms an ideal. In models of Tchain antichain, elements that are ordered by the mereology are not comparable in the partial ordering.

All ontologies within Hsubposet combine one of the ontologies in Figure 3.5 together with one of the ontologies in Figure 3.6 and one of the ontologies in Figure 3.7. In the

following sections, we will explore how different ontologies in Hsubposet serve as design patterns. We utilized the following structures from Hsubposet in our reduction of DOLCE: A subposet bundle11 is analogous to a mereological bundle: we find a generaliza- • tion of the part(x, y) relation from mereology by introducing a ternary relation tpart(x, y, z) that specifies a relativized parthood relation on sets of lines that are coincident with the same point. We also find a generalization of the leq(x, y) re- lation from the ordering theories introducing a ternary relation tleq(x, y, z) that specifies a relativized ordering relation on sets of lines that are coincident with the same point.

Subposet foliations12 are an amalgamation of mereological geometries and subposet • bundles.

Naming Convention for Bipartite Incidence Structure Theories

Due to the various combinations of incidence structures, the names of the theories in COLORE may appear confusing. Here we briefly outline the naming convention used to describe these incidence structure theories. Consider the theory Tideal cem wmg in COL- ORE13. The name ideal cem wmg is broken down as follows: 11http://code.google.com/p/colore/source/browse/trunk/ontologies/subposet_ bundle 12http://code.google.com/p/colore/source/browse/trunk/ontologies/subposet_ foliation 13http://code.google.com/p/colore/source/browse/trunk/ontologies/ mereological_geometry/ideal_cem_wmg.clif Chapter 3. Verification of DOLCE 40

filter ideal

upper_set lower_set

subposet

lower_reverse lower_preserve chain_antichain upper_preserve upper_reverse

subposet_root

mereology partial_ordering

Figure 3.5: Ontologies in Hsubposet: the hierarchy of theories of relationships between partially ordered sets. Solid arrows denote conservative extensions and dashed arrows denote non-conservative extensions. Chapter 3. Verification of DOLCE 41

cem_C cem_G cem_notG cem_notC

cem_mereology

mem_mereology

em_mereology

ppp_mm_mereology tree_mm_mereology ex_cm_mereology inclusion_space

ppp_m_mereology cm_mereology ex_mm_mereology

dense_mm_mereology

ex_m_mereology mm_mereology tree_mereology

prod_mereology sum_mereology

dense_mereology discrete_mereology

m_mereology

Figure 3.6: Ontologies in Hmereology. Solid arrows denote conservative extensions and dashed arrows denote non-conservative extensions. Chapter 3. Verification of DOLCE 42

discrete final_discrete linear_order initial_discrete bounded discrete initial_dense bounded dense final_dense dense linear_order no_end linear_order linear_order linear_order linear_order linear_order linear_order no_end

discrete dense linear_order linear_order bounded linear_order

discrete_chains tree linear_order discrete_forest

forest discrete dense semilinear_order semilinear_order

semiorder dense weak_separative

lattice semilinear_order interval_order partial total_preorder chains semiorder discrete dense weak_order partial_order semilattice partial_order

series_parallel

partial_order

discreteness max_exists min_exists quasi-order density

transitivity

Figure 3.7: Ontologies in Hordering. Solid arrows denote conservative extensions and dashed arrows denote non-conservative extensions. Chapter 3. Verification of DOLCE 43

ideal: collinear points form an ideal 14 in the global cem mereology • cem: ‘cem’ refers to cem mereology, which is the global mereology on all points • in this structure

wmg: collinear points form a weak mereology, wmg, which is a partial ordering •

3.1.4 The DOLCE Hierarchy (Hdolce) & Its Modules

From our partial modularization, we came up with the following modules for DOLCE that are each discussed in the sections that follow:

Tdolce taxonomy Tdolce present • •

Tdolce time mereology Tdolce temporary parthood • •

Tdolce mereology Tdolce constitution • •

The reduction for each theory breaks down according to DOLCE’s taxonomy, which is described in the next section. Figure 3.8 depicts how each DOLCE category (PD(x), ED(x), Q(x)) used in our modularization is associated with different mathematical struc- tures found in COLORE. ideal cem lower reflect down foliation ideal cem lower reflect down foliation ideal cem downward foliation ideal cem wmg dolce constitution ∪ ∪ ∪ ≡

ideal cem downward m foliation ideal cem downward m foliation ideal cem wmg ideal cem wmg dolce temporary parthood ∪ ∪ ∪ ≡

Non-Physical Endurant Physical Endurant NPED(x) PED(x)

ideal cem wmg ideal cem wmg ideal cem wmg dolce present ∪ ∪ ≡

Endurants Perdurants Qualities ED(x) PD(x) Q(x) Figure 3.8: Relationships between DOLCE modules with mathematical structures in COLORE.

14An ideal is a set closed under the P (x, y) and sum(x, y, z) relations. For any two points, its sum is also in the set. Chapter 3. Verification of DOLCE 44

3.2 DOLCE’s Taxonomy (Tdolce taxonomy)

The taxonomy of DOLCE is not axiomatically defined in first-order, but is depicted graphically in [51], so we have provided our own subsumption and disjointness axioms to describe the relationships between the various categories of particulars. In [51], the DOLCE taxonomy is specified in a finite set of explicitly introduced individuals, labelled as ΠX , of categories listed in Table 2.1. We define the overall set Π to be equivalent to the following:

ΠX = P T, AB, R, T R, T, P R, S, AR, Q, T Q, T L, P Q, SL, AQ, {

ED,PED,M,F,POB,APO,NAPO,NPED,NPOB,MOB,SOB,ASO,

SAG, SC, NASO, AS, P D, EV, ACH, ACC, ST V, ST, P RO }

Furthermore, each category in the taxonomy is broken down into the subcategories de- picted in Figure 2.1, so axiom definition Dd10 in [51] can be simplified as Φ which contains the leaves of the taxonomy: because of the assumption that the set Π is equivalent to

ΠX , L1(x),L2(x), ..., Ln(x) are leaves in ΠX :

LX (φ) (φ x L1(x) L2(x) ... Ln(x)) ≡ ≡ ∀ ∨ ∨ ∨

Consequently, Ad63 and Ad64 in [51] are instantiated by temporal (TL) and spatial locations (SL), time intervals (T), and space regions (S), as also specified in [48] and their DOLCE-CASL specification document. In our modularization, the taxonomy is a separate module that guides the remainder of this work; we used the taxonomy to help us decompose the ontology, as we will see in later sections. These taxonomic axioms are specified in first-order logic in Figures 3.9, Chapter 3. Verification of DOLCE 45

3.10, and 3.11, and can be found in COLORE15.

3.3 DOLCE’s Time Mereology (Tdolce time mereology)

Within DOLCE, there is a mereology on time intervals that is implicitly defined in the axiomatizations of temporal relations in [51]. We noticed patterns in how temporal relations are axiomatized in DOLCE where time intervals represent the temporal objects used throughout the ontology. Similar to the modularization of [48], we have formalized a module of DOLCE contains axioms that describe a mereology over time intervals. Recall

that, in Figure 3.2, all of the subsequent modules of DOLCE import Tdolce time mereology in

their axioms; this indicates that Tdolce time mereology plays a role in how the other DOLCE concepts are defined with respect to time intervals and how the mereology affects our usage of bipartite structures in the verification of these modules.

3.3.1 Axiomatization of Tdolce time mereology

In our axiomatization of Tdolce time mereology, we have adopted the original DOLCE mere- ology axioms, but have placed argument restrictions of using time intervals on the sorts. As well, we have added in the mereology axioms for overlap, difference, sum, implied parts of sum, and implied proper parts of sum axioms into this new time mereology. These axioms are outlined in the next section.

Figure 3.12 lists all of the axioms found in Tdolce time mereology; as well, the axioms can be found in COLORE16. In contrast to the axioms used by [48] in the HETS modular- ization, we were unable to utilize some of the axioms provided by [51] because of the fusion operator, σ, as it requires higher order logic. As well, the authors of [48] utilize variants of the sum(z, x, y) and dif(z, x, y) relations that are not found in COLORE. In

15http://colore.googlecode.com/svn/trunk/ontologies/dolce_taxonomy/dolce_ taxonomy.clif 16http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ time_mereology/dolce_time_mereology.clif Chapter 3. Verification of DOLCE 46

x ED(x) PD(x) Q(x) AB(x)) PT (x) (3.2.1) ∀ ∨ ∨ ∨ ⊃

x P ED(x) NPED(x) AS(x)) ED(x) (3.2.2) ∀ ∨ ∨ ⊃

x EV (x) STV (x)) PD(x) (3.2.3) ∀ ∨ ⊃

x T Q(x) PQ(x) AQ(x)) Q(x) (3.2.4) ∀ ∨ ∨ ⊃

x R(x)) AB(x) (3.2.5) ∀ ⊃

x M(x) F (x) POB(x)) PED(x) (3.2.6) ∀ ∨ ∨ ⊃

x NP OB(x)) NPED(x) (3.2.7) ∀ ⊃

x ACH(x) ACC(x)) EV (x) (3.2.8) ∀ ∨ ⊃

x ST (x) PRO(x)) STV (x) (3.2.9) ∀ ∨ ⊃

x T L(x)) TQ(x) (3.2.10) ∀ ⊃

x SL(x)) PQ(x) (3.2.11) ∀ ⊃

x T R(x) PR(x) AR(x)) R(x) (3.2.12) ∀ ∨ ∨ ⊃

x (AP O(x) NAP O(x)) POB(x) (3.2.13) ∀ ∨ ⊃

x MOB(x) SOB(x)) NPOB(x) (3.2.14) ∀ ∨ ⊃

x T (x)) TR(x) (3.2.15) ∀ ⊃

x S(x)) PR(x) (3.2.16) ∀ ⊃

x (ASO(x) NASO(x)) SOB(x) (3.2.17) ∀ ∨ ⊃

x (SAG(x) SC(x)) ASO(x) (3.2.18) ∀ ∨ ⊃

Figure 3.9: Axioms outlining the subsumption constraints of Tdolce taxonomy. Chapter 3. Verification of DOLCE 47

x (PT (x)) (ED(x) PD(x) Q(x) AB(x)) (3.2.19) ∀ ≡ ∨ ∨ ∨

x (ED(x)) PD(x) Q(x) AB(x) (3.2.20) ∀ ⊃ ¬ ∧ ¬ ∧ ¬

x (PD(x)) Q(x) AB(x) (3.2.21) ∀ ⊃ ¬ ∧ ¬

x (Q(x)) AB(x) (3.2.22) ∀ ⊃ ¬

x (ED(x)) (PED(x) NPED(x) AS(x)) (3.2.23) ∀ ≡ ∨ ∨

x (PED(x)) NPED(x) AS(x) (3.2.24) ∀ ⊃ ¬ ∧ ¬

x (NPED(x)) AS(x) (3.2.25) ∀ ⊃ ¬

x (PD(x)) (EV (x) STV (x)) (3.2.26) ∀ ≡ ∨

x (EV (x)) STV (x) (3.2.27) ∀ ⊃ ¬

x (Q(x)) (TQ(x) PQ(x) AQ(x)) (3.2.28) ∀ ≡ ∨ ∨

x (TQ(x)) PQ(x) AQ(x) (3.2.29) ∀ ⊃ ¬ ∧ ¬

x (PQ(x)) AQ(x) (3.2.30) ∀ ⊃ ¬

x (PED(x)) (M(x) F (x) POB(x)) (3.2.31) ∀ ≡ ∨ ∨

x (M(x)) F (x) POB(x) (3.2.32) ∀ ⊃ ¬ ∧ ¬

x (F (x)) POB(x) (3.2.33) ∀ ⊃ ¬

Figure 3.10: Axioms outlining the disjointness constraints of Tdolce taxonomy. Chapter 3. Verification of DOLCE 48

x (EV (x)) (ACH(x) ACC(x)) (3.2.34) ∀ ≡ ∨

x (ACH(x)) ACC(x) (3.2.35) ∀ ⊃ ¬

x (STV (x)) (ST (x) PRO(x)) (3.2.36) ∀ ≡ ∨

x (ST (x)) PRO(x) (3.2.37) ∀ ⊃ ¬

x (R(x)) (TR(x) PR(x) AR(x)) (3.2.38) ∀ ≡ ∨ ∨

x (TR(x)) PR(x) AR(x) (3.2.39) ∀ ⊃ ¬ ∧ ¬

x (PR(x)) AR(x) (3.2.40) ∀ ⊃ ¬

x (POB(x)) ((AP O(x) NAP O(x)) (3.2.41) ∀ ≡ ∨

x (AP O(x)) NAP O(x) (3.2.42) ∀ ⊃ ¬

x (NPOB(x)) ((MOB(x) SOB(x)) (3.2.43) ∀ ≡ ∨

x (MOB(x)) SOB(x) (3.2.44) ∀ ⊃ ¬

x (SOB(x)) ((ASO(x) NASO(x)) (3.2.45) ∀ ≡ ∨

x (ASO(x)) NASO(x) (3.2.46) ∀ ⊃ ¬

x (ASO(x)) ((SAG(x) SC(x)) (3.2.47) ∀ ≡ ∨

x (SAG(x)) SC(x) (3.2.48) ∀ ⊃ ¬

Figure 3.11: Axioms outlining the disjointness constraints of Tdolce taxonomy. Chapter 3. Verification of DOLCE 49

order to remain consistent with the mereological relations used in COLORE, we utilize

the mereological definitions found within the theory of classical mereology (Tcm mereology) in COLORE, but add temporal constraints on the parameters to restrict the relations to time objects found in DOLCE.

3.3.2 Reduction of Tdolce time mereology

In our reduction, we hypothesize that the parthood relation P (x, y), when constrained with time intervals T (x) and T (y), is equivalent to the parthood relation in the theory

of complete extensional mereology (Tcem mereology) in COLORE. As well, all constructs within this theory are equivalent to time intervals.

Theorem 3.3.1 Tdolce time mereology is definably equivalent to Tcem mereology.

Proof Let ∆ be the set of translation definitions

( x, y) part(x, y) P (x, y) T (x) T (y) ∀ ≡ ∧ ∧ ( x)(x = x) T (x) ∀ ≡

Tdolce time mereology ∆ = Tcem mereology ∪ | Let Π be the set of translation definitions

( x) T (x) (x = x) ∀ ≡ ( x, y) P (x, y) part(x, y) ∀ ≡

Tcem mereology Π = Tdolce time mereology ∪ | 

Using Prover9, we have shown that:

Tcem mereology Π = Tdolce time mereology and Tdolce time mereology ∆ = Tcem mereology ∪ | ∪ |

Proofs for this theorem can be found in COLORE17. 17http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ time_mereology/interprets/output/ Chapter 3. Verification of DOLCE 50

( x y (P (x, y) T (y) T (y))). (3.3.1) ∀ ∀ ⊃ ∧

( x y (P (x, y) (T (x) T (y)))). (3.3.2) ∀ ∀ ⊃ ≡

( x y (T (x) P (x, x))). (3.3.3) ∀ ∀ ⊃

( x y (T (x) T (y) P (x, y) P (y, x) x = y)). (3.3.4) ∀ ∀ ∧ ∧ ∧ ⊃

( x y z (T (x) T (y) P (x, y) P (y, z) P (x, z))). (3.3.5) ∀ ∀ ∀ ∧ ∧ ∧ ⊃

( x y (T (x) T (y) P (x, y) ( z(T (z) P (z, x) O(z, y))))). (3.3.6) ∀ ∀ ∧ ∧ ¬ ⊃ ∃ ∧ ∧ ¬

( x y (T (x) T (y) P (x, y) ( z(P (z, x) DJ(z, y) T (z))))). (3.3.7) ∀ ∀ ∧ ∧ ¬ ⊃ ∃ ∧ ∧

( x y (T (x) T (y) (PP (x, y) P (x, y) P (y, x)))). (3.3.8) ∀ ∀ ∧ ⊃ ≡ ∧ ¬

( x y (T (x) T (y) (O(x, y) ( z(P (z, x) P (z, y) T (z)))))). (3.3.9) ∀ ∀ ∧ ⊃ ≡ ∃ ∧ ∧

( x y (T (x) T (y) (DJ(x, y) O(x, y)))). (3.3.10) ∀ ∀ ∧ ⊃ ≡ ¬

( x y (T (x) T (y) (U(x, y) ( z(P (x, z) P (y, z) T (z)))))). (3.3.11) ∀ ∀ ∧ ⊃ ≡ ∃ ∧ ∧

( x AtP (x) T (x) ( y(T (y) P (y, x) y = x)))). (3.3.12) ∀ ≡ ∧ ∀ ∧ ⊃

( x y (T (x) T (y) U(x, y) ( z (T (z) ( w(T (w∀)∀ (O(w,∧ z) O(∧w, x) O⊃(w, y)))))))). (3.3.13) ∃ ∧ ∀ ⊃ ≡ ∨

( x y (T (x) T (y) O(x, y) ( z (T (z) ( w(T (w)∀ ∀(PP (w, z∧) PP∧(w, x) PP⊃ (w, y)))))))). (3.3.14) ∃ ∧ ∀ ⊃ ≡ ∧

( x y z (T (x) T (y) T (z) (SUM(z, x, y) ( w(∀T (∀w)∀ (O(w,∧ z) O∧(w, x) ⊃O(w, y))))))). (3.3.15) ≡ ∀ ⊃ ≡ ∨

Figure 3.12: Axioms of Tdolce time mereology. Chapter 3. Verification of DOLCE 51

3.4 DOLCE’s Mereology (Tdolce mereology)

Recall from Chapter2 that the distinction between endurants and perdurants introduced two kinds of parthood relations: atemporal and time-indexed parthood. Here we consider parthood for entities which do not change in time. Within the Tdolce mereology module, we have axioms that assign class restrictions to the arguments found in the binary atempo- ral parthood relation, P (x, y) (Axioms 3.4.1 to 3.4.7). As well, the authors of [51] have indicated that they have adopted the axioms of atomic General Extensional Mereology (GEM), along with the classical definitions of overlap, underlap, disjoint, proper part, and mereological sum (Axioms 3.4.8 to Axioms 3.4.18). Figures 3.13 and 3.14 list all

18 of the axioms found in Tdolce mereology; as well, the axioms can be found in COLORE . We note here that verification of this module was not carried out since all of the mod- ules that follow focused primarily on mereologies on time and reused axioms from the

Tdolce time mereology module.

3.5 A Taxonomy of Lines (Ttaxonomy)

In the DOLCE taxonomy, there are subclasses and disjoint sets of categories; we took a bottom-up approach in our modularization and paired the categories found in Fig- ure 3.15a with the structures of lines seen in Figure 3.15b. In Figure 3.15a, the abstract category (AB) that contains temporal objects T (x) from Figure 2.1 is not included; this

is due to the fact that temporal objects are handled by Tdolce time mereology. This taxonomy of lines is used to make distinctions between the various subclasses of lines and its axiomatization in first-order logic is shown in Figure 3.16 and can be accessed in COLORE19. From this taxonomy, we have three disjoint sets of lines that can 18http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ mereology/dolce_mereology.clif 19http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ taxonomy/taxonomy.clif Chapter 3. Verification of DOLCE 52

( x y (P (x, y) (AB(x) PD(x)) (AB(y) PD(y)))). (3.4.1) ∀ ∀ ⊃ ∨ ∧ ∨

( x y (P (x, y) (PD(x) PD(y)))). (3.4.2) ∀ ∀ ⊃ ≡

( x y (P (x, y) (AB(x) AB(y)))). (3.4.3) ∀ ∀ ⊃ ≡

( x y (P (x, y) (TR(x) R(x)) (TR(x) TR(y)))). (3.4.4) ∀ ∀ ∧ ⊃ ⊃ ≡

( x y (P (x, y) (PR(x) R(x)) (PR(x) PR(y)))). (3.4.5) ∀ ∀ ∧ ⊃ ⊃ ≡

( x y (P (x, y) (AR(x) R(x)) (AR(x) AR(y)))). (3.4.6) ∀ ∀ ∧ ⊃ ⊃ ≡

( x y (AB(x) PD(x) P (x, x))). (3.4.7) ∀ ∀ ∨ ⊃

Figure 3.13: Axioms of Tdolce mereology. be equated with the classification structure of particulars in DOLCE, which is specified as follows and depicted graphically in Figure 3.15a:

( x) L1(x) ED(x) ∀ ≡

( x) L2(x) PD(x) ∀ ≡

( x) L3(x) Q(x) ∀ ≡

( x) L4(x) PED(x) ∀ ≡

( x) L5(x) NPED(x) ∀ ≡ Chapter 3. Verification of DOLCE 53

( x y (P (x, y) P (y, x) x = y)). (3.4.8) ∀ ∀ ∧ ⊃

( x y z (P (x, y) P (y, z) P (x, z))). (3.4.9) ∀ ∀ ∀ ∧ ⊃

( x y ((AB(x) PD(x)) P (x, y) ( z(P (z, x) O(z, y))))). (3.4.10) ∀ ∀ ∨ ∧ ¬ ⊃ ∃ ∧ ¬

( x y ( P (x, y) ( z(P (z, x) DJ(z, y))))). (3.4.11) ∀ ∀ ¬ ⊃ ∃ ∧

( x y (PP (x, y) P (x, y) P (y, x))). (3.4.12) ∀ ∀ ≡ ∧ ¬

( x y (O(x, y) ( z(P (z, x) P (z, y))))). (3.4.13) ∀ ∀ ≡ ∃ ∧

( x y (DJ(x, y) O(x, y))). (3.4.14) ∀ ∀ ≡ ¬

( x y (U(x, y) ( z (P (x, z) P (y, z))))). (3.4.15) ∀ ∀ ≡ ∃ ∧

( x (AtP (x) ( y (P (y, x) y = x)))). (3.4.16) ∀ ≡ ∀ ⊃

( x y (U(x, y) ( z v (O(v, z) O(v, x) O(v, y))))). (3.4.17) ∀ ∀ ⊃ ∃ ∀ ≡ ∨

( x y (O(x, y) ( z v (PP (v, z) PP (v, x) PP (v, y))))). (3.4.18) ∀ ∀ ⊃ ∃ ∀ ≡ ∧

( x y z (SUM(z, x, y) ( w (T (w) (O(w, z) O(w, x) O(w, y)))))). (3.4.19) ∀ ∀ ∀ ≡ ∀ ⊃ ≡ ∨

Figure 3.14: Axioms of Tdolce mereology.

DOLCE Categories PT AB(x) \ L

ED(x) PD(x) Q(x) L1 L2 L3

PED(x) NPED(x) L4 L5 (a) A taxonomy of DOLCE categories. (b) A taxonomy of lines.

Figure 3.15: Corresponding taxonomies of DOLCE categories and lines. Chapter 3. Verification of DOLCE 54

( x(L1(x) L2(x)) (3.5.1) ∀ ⊃ ¬

( x)(L1(x) L3(x)) (3.5.2) ∀ ⊃ ¬

( x)(L2(x) L3(x)) (3.5.3) ∀ ⊃ ¬

( x)(L4(x) L1(x)) (3.5.4) ∀ ⊃

( x)(L5(x) L1(x)) (3.5.5) ∀ ⊃

( x)(L4(x) L5(x)) (3.5.6) ∀ ⊃ ¬

Figure 3.16: Axiomatization of Ttaxonomy, used in our DOLCE modularization.

3.6 Theory of Being Present (Tdolce present)

Recall that the concept of being present is modelled by the PRE(x, t) relation, which is read as “x is present at time t.” As we will see in the axiomatization of this module, there are different ways of being in time: existing in time versus occurring in time, or being wholly present versus being partially present (recall the distinction between endurants and perdurants).

3.6.1 Axiomatization of Tdolce present

In this theory, we have axioms that describe the existence of an endurant ED(x), per- durant PD(x), or a quality Q(x) during a time interval T (x). Axiom 3.6.2 outlines how the parthood relation P (x, y) applies to time intervals as well; if an endurant, perdurant, or quality exists during a time interval t, and t1 is part of t, then it must also exist at t1. Axiom 3.6.4 shows that if an endurant, perdurant, or quality exists at two different time intervals t1 and t2, and that the time interval t is the sum of these two intervals, then it must also exist during t. Figure 3.17 lists all of the axioms found in Tdolce present; as well, Chapter 3. Verification of DOLCE 55

( x)(ED(x) PD(x) Q(x)) ( t) PRE(x, t) (3.6.1) ∀ ∨ ∨ ⊃ ∃

( x, t, t1) PRE(x, t) P (t1, t) PRE(x, t1) (3.6.2) ∀ ∧ ⊃

( x, t) PRE(x, t) T (t) (3.6.3) ∀ ⊃

( x, t, t1, t2) PRE(x, t1) PRE(x, t2) SUM(t, t1, t2) PRE(x, t) (3.6.4) ∀ ∧ ∧ ⊃

Figure 3.17: Axioms of Tdolce present.

the axioms can be found in COLORE20.

3.6.2 Reduction of Tdolce present

We hypothesized that the primitive PRE(x, y) relation in DOLCE is equivalent to the incidence relation in(x, y) found in mereology with sort restrictions on its parameters: a point x which is incident on a line y is equivalent to an endurant ED(x), perdurant PD(x), or quality Q(x) that is present during a time interval T (x).

Lemma 3.6.1 Let ∆ be the set of translation definitions

( x, y)in(x, y) ∀ ≡ ((PRE(x, y) T (y) (ED(x) PD(x) Q(x))) ∧ ∧ ∨ ∨ (PRE(y, x) T (x) (ED(y) PD(y) Q(y))) ∨ ∧ ∧ ∨ ∨ ((x = y) (ED(y) PD(y) Q(y) T (y)))) ∨ ∧ ∨ ∨ ∨ ( x) line(x) ED(x) PD(x) Q(x) ∀ ≡ ∨ ∨ ( x) point(x) T (x) ∀ ≡ ( x, y) part(x, y) P (x, y) T (x) T (y) ∀ ≡ ∧ ∧

( x) L1(x) ED(x) ∀ ≡ ( x) L2(x) PD(x) ∀ ≡ 20http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ present/dolce_present.clif Chapter 3. Verification of DOLCE 56

( x) L3(x) Q(x) ∀ ≡ ( x) L4(x) PED(x) ∀ ≡ ( x) L5(x) NPED(x) ∀ ≡

Tdolce present ∆ = Tideal cem wmg Ttaxonomy ∪ | ∪ 

Lemma 3.6.2 Let Π be the set of translation definitions

( x, y) PRE(x, y) ∀ ≡ (in(y, x) line(x) point(y)) ∧ ∧ ( x) T (x) point(x) ∀ ≡ ( x) ED(x) line(x) L1(x) ∀ ≡ ∧ ( x) PD(x) line(x) L2(x) ∀ ≡ ∧ ( x) Q(x) line(x) L3(x) ∀ ≡ ∧ ( x, y) P (x, y) part(x, y) ∀ ≡

Tideal cem wmg Ttaxonomy Π = Tdolce present ∪ ∪ | 

Theorem 3.6.3 Tdolce present is definably equivalent to Tideal cem wmg Ttaxonomy. ∪

Proof Using Prover9, we have shown that: By Lemma 3.6.1 Tdolce present interprets Tideal cem wmg Ttaxonomy. ∪ By Lemma 3.6.2, Tideal cem wmg Ttaxonomy interprets Tdolce present. ∪

Proofs for this theorem can be found in COLORE21.

3.7 Theory of Temporary Parthood (Tdolce temporary parthood)

Recall that time-indexed parthood holds for endurants since it is necessary to know when a specific parthood relationship holds [51]. We revisit the two notions of time-indexed

21http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ present/interprets/output/ Chapter 3. Verification of DOLCE 57

parthood as defined in [51], where an endurant can be mereologically constant (endurants remain the same during its entire life: if it gains or loses parts, it ceases to exist), or mereologically invariant (endurants always keep their parts across all possible words, such as amounts of matter).

3.7.1 Axiomatization of Tdolce temporary parthood

In the original DOLCE axioms, the relation for temporary parthood is of the form P (x, y, t), but having the same names for relations of different arities, such as P (x, y) to denote atemporal parthood, causes issues in Prover922. Consequently, all temporal rela- tions were renamed by appending a ‘t’ in front of the relation name to distinguish these temporal relations with their atemporal counterparts. The relation tP (x, y, t) stands for ‘x is part of y during time t, and analogously for temporary overlap tO(x, y, t) and temporary proper part tP P (x, y, t). Figure 3.18 lists all of the axioms found in

23 Tdolce temporary parthood; as well, the axioms can be found in COLORE . An observation from the temporary parthood axioms is that the relation tP (x, y, t) only affects endurants (Axiom 3.7.1): more specifically, Axiom 3.7.2 applies to physical endurants PED(x), and Axiom 3.7.3 applies to non-physical endurants NPED(x). Per- durants PD(x) and Qualities Q(x) are not affected by these temporary parthood axioms, so the verification tasks for these two DOLCE categories are different from the endurants, as described below.

3.7.2 Reduction of Tdolce temporary parthood

Within the theory of temporary parthood in DOLCE, we noticed that the tP (x, y, t) relation only applied to endurants, so the verification tasks were broken down into three

22Input files in Prover9 cannot have a symbol with multiple arities; for example, having P (x, y) and P (x, y, t) in an input file will return an error because the theorem prover is unable to discern whether these are the same relations or one is a relation and the other is a function. 23http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ temporary_parthood/dolce_temporary_parthood.clif Chapter 3. Verification of DOLCE 58

( x, y, t) tP (x, y, t) ED(x) ED(y) T (t) (3.7.1) ∀ ⊃ ∧ ∧

( x, y, t) tP (x, y, t) (PED(x) PED(y)) (3.7.2) ∀ ⊃ ≡

( x, y, t) tP (x, y, t) (NPED(x) NPED(y)) (3.7.3) ∀ ⊃ ≡

( x, y, z, t) tP (x, y, t) tP (y, z, t) tP (x, z, t) (3.7.4) ∀ ∧ ⊃

( x, y, z, t) ED(x) ED(y) PRE(x, t) PRE(y, t) tP (x, y, t) ∀ ∧ ∧ ∧ ∧ ¬

( z) tP (z, x, t) tO(z, y, t) (3.7.5) ⊃ ∃ ∧ ¬

( x, t) ED(x) PRE(x, t) tP (x, x, t) (3.7.6) ∀ ∧ ⊃

( x, y, t) tP (x, y, t) PRE(x, t) PRE(y, t) (3.7.7) ∀ ⊃ ∧

( x, y, t1) tP (x, y, t1) (( t2) P (t2, t1) tP (x, y, t2)) (3.7.8) ∀ ⊃ ∀ ⊃

( x, y, t) PRE(x, y, t) PRE(y, t) tP (x, y, t) ( z) tP (x, y, t) tDJ(z, y, t) (3.7.9) ∀ ∧ ∧ ¬ ⊃ ∃ ∧

( x, y, t) tU(x, y, t) ( z)( v)(tO(v, z, t) (tO(v, x, t) tO(v, y, t))) (3.7.10) ∀ ⊃ ∃ ∀ ≡ ∨

( x, y, t) tO(x, y, t) ( z)( v)(tP P (v, z, t) (tP P (v, x, t) tP P (v, y, t))) (3.7.11) ∀ ⊃ ∃ ∀ ≡ ∧

Figure 3.18: Axioms of Tdolce temporary parthood. Chapter 3. Verification of DOLCE 59

parts: a task to handle physical endurants PED(x), a task to handle non-physical en- durants NPED(x), and a task to handle both perdurants PD(x) and qualities Q(x). Collectively, PED(x) and NPED(x) make up endurants ED(x), but since they are dis-

24 joint constructs , we were required to create two sets of translation definitions, ∆1 and

∆2, to handle these endurant subcategories. The translation definitions for PD(x) and

Q(x) are grouped together in ∆3 because the tP (x, y, t) does not involve either of these constructs.

Similar to the reduction of Tdolce present, we hypothesized that the primitive PRE(x, y) relation in DOLCE is equivalent to the incidence relation in(x, y) found in mereology with sort restrictions on its parameters: a point x which is incident on a line y is equivalent to either a physical endurant PED(x), non-physical perdurant NPED(x), or perdurant PD(x) or quality Q(x) that is present during a time interval T (x).

Lemma 3.7.1 Let ∆1 be the set of translation definitions

( x, y) part1(x, y) P (x, y) T (x) T (y) ∀ ≡ ∧ ∧ ( x, y)(in1(x, y) ∀ ≡ ((PRE(x, y) T (y) PED(x)) ∧ ∧ (PRE(y, x) T (x) PED(y)) ∨ ∧ ∧ ((x = y) (PED(y) T (y)))) ∨ ∧ ∨ ( x) point1(x) T (x) ∀ ≡ ( x) line1(x) PED(x) ∀ ≡ ( x, y, z) tpart1(x, y, z) tP (x, y, z) PED(x) PED(y) ∀ ≡ ∧ ∧

( x) L1(x) ED(x) ∀ ≡ ( x) L2(x) PD(x) ∀ ≡ ( x) L3(x) Q(x) ∀ ≡ ( x) L4(x) PED(x) ∀ ≡ ( x) L5(x) NPED(x) ∀ ≡ 24 Recall Axioms 3.2.23 to 3.2.25 in Tdolce taxonomy. Chapter 3. Verification of DOLCE 60

1 Tdolce temporary parthood ∆1 = T Ttaxonomy ∪ | ideal cem downward m foliation ∪ 

Lemma 3.7.2 Let ∆2 be the set of translation definitions

( x, y) part2(x, y) P (x, y) T (x) T (y) ∀ ≡ ∧ ∧ ( x, y)(in2(x, y) ∀ ≡ ((PRE(x, y) T (y) NPED(x)) ∧ ∧ (PRE(y, x) T (x) NPED(y)) ∨ ∧ ∧ ((x = y) (NPED(y) T (y)))) ∨ ∧ ∨ ( x) point2(x) T (x) ∀ ≡ ( x) line2(x) NPED(x) ∀ ≡ ( x, y, z) tpart2(x, y, z) tP (x, y, z) NPED(x) NPED(y) ∀ ≡ ∧ ∧

( x) L1(x) ED(x) ∀ ≡ ( x) L2(x) PD(x) ∀ ≡ ( x) L3(x) Q(x) ∀ ≡ ( x) L4(x) PED(x) ∀ ≡ ( x) L5(x) NPED(x) ∀ ≡

2 Tdolce temporary parthood ∆2 = T Ttaxonomy ∪ | ideal cem downward m foliation ∪ 

Lemma 3.7.3 Let ∆3 be the set of translation definitions

( x, y)in3(x, y) ∀ ≡ ((PRE(x, y) T (y) (PD(x) Q(x))) ∧ ∧ ∨ (PRE(y, x) T (x) (PD(y) Q(x))) ∨ ∧ ∧ ∨ ((x = y) (PD(y) Q(y) T (y)))) ∨ ∧ ∨ ∨ ( x) line3(x) (PD(x) Q(x)) ∀ ≡ ∨ ( x) point3(x) T (x) ∀ ≡ ( x, y) part3(x, y) P (x, y) T (x) T (y) ∀ ≡ ∧ ∧ Chapter 3. Verification of DOLCE 61

( x) L1(x) ED(x) ∀ ≡ ( x) L2(x) PD(x) ∀ ≡ ( x) L3(x) Q(x) ∀ ≡ ( x) L4(x) PED(x) ∀ ≡ ( x) L5(x) NPED(x) ∀ ≡

3 Tdolce temporary parthood ∆3 = T Ttaxonomy ∪ | ideal cem wmg ∪ 

Lemma 3.7.4 Let Π be the set of translation definitions

( x, y, z) tP (x, y, z) tpart1(x, y, z) tpart2(x, y, z) ∀ ≡ ∨ ( x, y) PRE(x, y) ∀ ≡ ((in1(y, x) point1(y) line1(x)) (in2(y, x) point2(y) line2(x)) ∧ ∧ ∨ ∧ ∧ (in3(y, x) point3(y) line3(x))) ∨ ∧ ∧ ( x) T (x) point1(x) ∀ ≡ ( x) T (x) point2(x) ∀ ≡ ( x) T (x) point3(x) ∀ ≡ ( x) ED(x) line1(x) line2(x) ∀ ≡ ∨ 3 ( x) PD(x) line (x) L2(x) ∀ ≡ ∧ 3 ( x) Q(x) line (x) L3(x) ∀ ≡ ∧ ( x) PED(x) line1(x) ∀ ≡ ( x) NPED(x) line2(x) ∀ ≡ ( x, y) P (x, y) part1(x, y) ∀ ≡ ( x, y) P (x, y) part2(x, y) ∀ ≡ ( x, y) P (x, y) part3(x, y) ∀ ≡ ( x) ED(x) L1(x) ∀ ≡ ( x) PED(x) L4(x) ∀ ≡ ( x) NPED(x) L5(x) ∀ ≡

T 1 T 2 ideal cem downward m foliation ∪ ideal cem downward m foliation 3 T Ttaxonomy Π = Tdolce temporary parthood ∪ ideal cem wmg ∪ ∪ | Chapter 3. Verification of DOLCE 62



Theorem 3.7.5 Tdolce temporary parthood is definably equivalent to

T 1 T 2 ideal cem downward m foliation ∪ ideal cem downward m foliation

3 T Ttaxonomy ∪ ideal cem wmg ∪

Proofs for this theorem can be found in COLORE25.

3.8 Theory of Constitution (Tdolce constitution)

Recall that the authors of [51] make the distinction that constitution is not considered to be parthood. DOLCE describes the concept of constitution as the co-location of different entities in the same space-time since entities are given incompatible essential properties [51]. For example, a vase is constituted by an amount of clay, but the vase itself is not an amount of clay. The vase and clay are considered to be different things due to their properties: for instance, we say that a vase has a handle, but not that a piece of clay has a handle.

3.8.1 Axiomatization of Tdolce constitution

Similar to the axioms of Tdolce temporary parthood, the axioms in the theory of constitution only applied to the physical endurants PED(x), non-physical endurants NPED(x), and perdurants PD(x); these correspond to Axioms 3.8.2 to 3.8.4, respectively. Figure 3.19 lists all of the axioms found in Tdolce constitution; as well, the axioms can be found in COLORE26. We observed that the constitution axioms require the first two arguments 25http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ temporary_parthood/interprets/output/ 26http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ constitution/dolce_constitution.clif Chapter 3. Verification of DOLCE 63

( x, y, t) K(x, y, t) (ED(x) PD(x)) (ED(y) PD(y)) T (t) (3.8.1) ∀ ⊃ ∨ ∧ ∨ ∧

( x, y, t) K(x, y, t) (PED(x) PED(y)) (3.8.2) ∀ ⊃ ≡

( x, y, t) K(x, y, t) (NPED(x) NPED(y)) (3.8.3) ∀ ⊃ ≡

( x, y, t) K(x, y, t) (PD(x) PD(y)) (3.8.4) ∀ ⊃ ≡

( x, y, t) K(x, y, t) K(y, x, t) (3.8.5) ∀ ⊃ ¬

( x, y, z, t) K(x, y, t) K(y, z, t) K(x, z, t) (3.8.6) ∀ ∧ ⊃

( x, y, t) K(x, y, t) PRE(x, t) PRE(y, t) (3.8.7) ∀ ⊃ ∧

( x, y, t) K(x, y, t) (( t2) P (t2, t) K(x, y, t2)) (3.8.8) ∀ ≡ ∀ ⊃

( x, y, t, y1) K(x, y, t) tP (y1, y, t) ( x1) tP (x1, x, t) K(x1, y1, t) (3.8.9) ∀ ∧ ⊃ ∃ ∧

Figure 3.19: Axioms of Tdolce temporary constitution.

to be of the same category; for example, only two non-physical endurants NPED(x) can constitute each other during a given time interval t. The remainder of the axioms show that constitution is irreflexive, transitive, enforces the existence of the two endurants or perdurants that are being constituted, constitution still holds for subintervals of a time interval, and that temporary parts of an endurant are also constituted (Axioms 3.8.5 to 3.8.9, respectively).

3.8.2 Reduction of Tdolce constitution

Within the theory of constitution in DOLCE, we noticed that the K(x, y, t) relation only applied to endurants and perdurants, so the verification tasks were broken down into four parts: a task to handle physical endurants PED(x), a task to handle non-physical Chapter 3. Verification of DOLCE 64

endurants NPED(x), a task to handle perdurants PD(x), and a task to handle qualities Q(x). Collectively, PED(x) and NPED(x) make up endurants ED(x), but since they

27 are disjoint constructs , we created two sets of translation definitions, ∆1 and ∆4, to handle these endurant subcategories. The translation definitions for PD(x) can be found in ∆2, and the translation definitions for Q(x) are in ∆3.

Similar to the reduction of Tdolce present, we hypothesized that the primitive PRE(x, y) relation in DOLCE is equivalent to the incidence relation in(x, y) found in mereology with sort restrictions on its parameters: a point x which is incident on a line y is equivalent to either a physical endurant PED(x), non-physical perdurant NPED(x), or perdurant PD(x) or quality Q(x) that is present during a time interval T (x).

Lemma 3.8.1 Let ∆1 be the set of translation definitions

( x, y) part1(x, y) P (x, y) T (x) T (y) ∀ ≡ ∧ ∧ ( x, y)(in1(x, y) ∀ ≡ ((PRE(x, y) T (y) PED(x)) ∧ ∧ (PRE(y, x) T (x) PED(y)) ∨ ∧ ∧ ((x = y) (ED(y) T (y)))) ∨ ∧ ∨ ( x) point1(x) T (x) ∀ ≡ ( x) line1(x) PED(x) ∀ ≡ ( x, y, z) tpart1(x, y, z) tP (x, y, z) PED(x) PED(y) T (z) ∀ ≡ ∧ ∧ ∧ ( x, y, z) tppart1(x, y, z) tP (x, y, z) (x = y) PED(x) PED(y) T (z) ∀ ≡ ∧ 6 ∧ ∧ ∧ ( x, y, z) tlt1(x, y, z) K(x, y, z) PED(x) PED(y) T (z) ∀ ≡ ∧ ∧ ∧ ( x, y, z)tleq1(x, y, z) (K(x, y, z) (PRE(x, z) (x = y))) PED(x) PED(y) T (z) ∀ ≡ ∨ ∧ ∧ ∧ ∧ ( x) poset element1(x) PED(x) ∀ ≡ ( x) mereo element1(x) PD(x) ∀ ≡

( x) L1(x) ED(x) ∀ ≡ ( x) L2(x) PD(x) ∀ ≡ ( x) L3(x) Q(x) ∀ ≡ 27 Recall Axioms 3.2.23 to 3.2.25 in Tdolce taxonomy). Chapter 3. Verification of DOLCE 65

( x) L4(x) PED(x) ∀ ≡ ( x) L5(x) NPED(x) ∀ ≡

1 Tdolce constitution ∆1 = T Ttaxonomy ∪ | ideal cem lower reflect down foliation ∪ 

Lemma 3.8.2 Let ∆2 be the set of translation definitions

( x, y) part2(x, y) P (x, y) T (x) T (y) ∀ ≡ ∧ ∧ ( x, y)(in2(x, y) ∀ ≡ ((PRE(x, y) T (y) PD(x)) ∧ ∧ (PRE(y, x) T (x) PD(y)) ∨ ∧ ∧ ((x = y) (PD(y) T (y))) ∨ ∧ ∨ ( x) point2(x) T (x) ∀ ≡ ( x) line2(x) PD(x) ∀ ≡ ( x, y, z) tpart2(x, y, z) (K(x, y, z) (PRE(x, z) (x = y))) PD(x) PD(y) T (z) ∀ ≡ ∧ ∨ ∧ ∧ ∧ ( x, y, z) tppart2(x, y, z) K(x, y, z) PD(x) PD(y) T (z) ∀ ≡ ∧ ∧ ∧

( x) L1(x) ED(x) ∀ ≡ ( x) L2(x) PD(x) ∀ ≡ ( x) L3(x) Q(x) ∀ ≡ ( x) L4(x) PED(x) ∀ ≡ ( x) L5(x) NPED(x) ∀ ≡

2 Tdolce constitution ∆2 = T Ttaxonomy ∪ | ideal cem downward m foliation ∪ 

Lemma 3.8.3 Let ∆3 be the set of translation definitions

( x, y)(in3(x, y) ∀ ≡ ((PRE(x, y) T (y) Q(x)) ∧ ∧ (PRE(y, x) T (x) Q(y)) ∨ ∧ ∧ ((x = y) (Q(y) T (y))))) ∨ ∧ ∨ ( x) line3(x) Q(x) ∀ ≡ Chapter 3. Verification of DOLCE 66

( x) point3(x) T (x) ∀ ≡ ( x, y) part3(x, y) P (x, y) T (x) T (y) ∀ ≡ ∧ ∧

( x) L1(x) ED(x) ∀ ≡ ( x) L2(x) PD(x) ∀ ≡ ( x) L3(x) Q(x) ∀ ≡ ( x) L4(x) PED(x) ∀ ≡ ( x) L5(x) NPED(x) ∀ ≡

3 Tdolce constitution ∆3 = T Ttaxonomy ∪ | ideal cem wmg ∪ 

Lemma 3.8.4 Let ∆4 be the set of translation definitions

( x, y) part4(x, y) P (x, y) T (x) T (y) ∀ ≡ ∧ ∧ ( x, y)(in4(x, y) ∀ ≡ ((PRE(x, y) T (y) NPED(x)) ∧ ∧ (PRE(y, x) T (x) NPED(y)) ∨ ∧ ∧ ((x = y) (NPED(y) T (y)))) ∨ ∧ ∨ ( x) point4(x) T (x) ∀ ≡ ( x) line4(x) NPED(x) ∀ ≡ ( x, y, z) tpart4(x, y, z) tP (x, y, z) NPED(x) NPED(y) T (z) ∀ ≡ ∧ ∧ ∧ ( x, y, z) tppart4(x, y, z) tP (x, y, z) (x = y) NPED(x) NPED(y) T (z) ∀ ≡ ∧ 6 ∧ ∧ ∧ ( x, y, z) tlt4(x, y, z) K(x, y, z) NPED(x) NPED(y) T (z) ∀ ≡ ∧ ∧ ∧ ( x, y, z)tleq4(x, y, z) (K(x, y, z) (PRE(x, z) (x = y))) NPED(x) NPED(y) T (z) ∀ ≡ ∨ ∧ ∧ ∧ ∧ ( x) poset element4(x) NPED(x) ∀ ≡ ( x) mereo element4(x) PD(x) ∀ ≡

( x) L1(x) ED(x) ∀ ≡ ( x) L2(x) PD(x) ∀ ≡ ( x) L3(x) Q(x) ∀ ≡ ( x) L4(x) PED(x) ∀ ≡ ( x) L5(x) NPED(x) ∀ ≡ Chapter 3. Verification of DOLCE 67

4 Tdolce constitution ∆4 = T ∪ | ideal cem lower reflect down foliation 

Lemma 3.8.5 Let Π be the set of translation definitions

( x, y, z) K(x, y, z) (tlt1(x, y, z) tlt4(x, y, t) tppart2(x, y, t)) ∀ ≡ ∨ ∨ ( x, y, z) tP (x, y, z) (tpart1(x, y, z) tpart4(x, y, z)) ∀ ≡ ∨ ( x, y) PRE(x, y) (in1(y, x) point1(y) line1(x)) (in2(y, x) point2(y) line2(x)) ∀ ≡ ∧ ∧ ∨ ∧ ∧ (in3(y, x) point3(y) line3(x)) (in4(y, x) point4(y) line4(x)) ∨ ∧ ∧ ∨ ∧ ∧ ( x, y) P (x, y) part1(x, y) ∀ ≡ ( x, y) P (x, y) part2(x, y) ∀ ≡ ( x, y) P (x, y) part3(x, y) ∀ ≡ ( x, y) P (x, y) part4(x, y) ∀ ≡ ( x) PED(x) poset element1(x) ∀ ≡ ( x) NPED(x) poset element4(x) ∀ ≡ ( x) PD(x) mereo element1(x) ∀ ≡ ( x) PD(x) mereo element4(x) ∀ ≡ ( x) T (x) point1(x) ∀ ≡ ( x) T (x) point2(x) ∀ ≡ ( x) T (x) point3(x) ∀ ≡ ( x) T (x) point4(x) ∀ ≡ ( x) ED(x) line1(x) line4(x) ∀ ≡ ∨ ( x) PED(x) line1(x) ∀ ≡ ( x) NPED(x) line4(x) ∀ ≡ ( x) PD(x) line2(x) ∀ ≡ ( x) Q(x) line3(x) ∀ ≡ ( x) ED(x) L1(x) ∀ ≡ ( x) PD(x) L2(x) ∀ ≡ ( x) Q(x) L3(x) ∀ ≡ ( x) PED(x) L4(x) ∀ ≡ ( x) NPED(x) L5(x) ∀ ≡ Chapter 3. Verification of DOLCE 68

T 1 T 4 ideal cem lower reflect down foliation ∪ ideal cem lower reflect down foliation 2 3 T T Ttaxonomy Π = Tdolce constitution ∪ ideal cem downward m foliation ∪ ideal cem wmg ∪ ∪ | 

Theorem 3.8.6 Tdolce constitution is definably equivalent to

T 1 T 2 ideal cem lower reflect down foliation ∪ ideal cem downward m foliation

T 3 T 4 ∪ ideal cem wmg ∪ ideal cem lower reflect down foliation

Proofs for this theorem can be found in COLORE28.

3.9 Summary of DOLCE Modules

From what we have seen in this chapter, our modularization makes distinctions between endurants and perdurants, especially in the Tdolce temporary parthood and Tdolce constitution modules. We have provided the axioms of each module in first-order logic and in CLIF, and have utilized the modularization technique presented in [29]. From our modulariza- tion, the following observations have been made:

Our modularization of DOLCE is coarser-grained than the modules presented in • [48].

Every module in our modularization is a module of DOLCE. • Every module in [48] is a module of the modules we have presented in this work. • We divided the reduction for each module based on whether or not the axioms • involved endurants or perdurants while preserving the taxonomic structure found in the original DOLCE axioms.

28http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ constitution/interprets/output/ Chapter 4

Ontology Composition: Interpretations Between DOLCE & COLORE

Recall from the previous chapter that DOLCE is built up of modules shown in Figure 3.2.

In this chapter, we examine how Tdolce participation and Tdolce present can be mapped with

Tpsl core and other mathematical theories found in COLORE, and discuss the steps needed to bridge these theories together. As discussed in Chapter2, the process of verification involves finding all possible models of a given ontology. This means that we map the DOLCE ontology with math- ematical theories found in COLORE. In the introductory section of this thesis, we had discussed our motivations and interest in examining how DOLCE is related to other on- tologies; DOLCE is known as an ontology of endurants and perdurants, but we can also say that it is an ontology of processes and objects. Thus, we were curious in examining how DOLCE is related to other ontologies that describe processes and objects. Current process ontologies include the Suggested Upper Merged Ontology (SUMO), OpenCyc, Basic Formal Ontology (BFO), and PSL; we had considered analyzing the first three

69 Chapter 4. Interpretations Between DOLCE & COLORE 70

ontologies, but due to the large number of axioms found in these ontologies1 and dif- ferent logic languages in which they are written2, we opted to analyze an ontology of comparable size that was already defined in first-order logic. Due to prior familiarity with PSL and that it is already available in COLORE, we opted to use PSL to identify any relationships it may have with DOLCE, and whether DOLCE makes additional onto- logical commitments with these process-related concepts and to analyze the relationship between them.

4.1 Relationship with PSL and COLORE Theories

From what we have seen with DOLCE, time intervals are used to describe temporal

objects in Tdolce temporary parthood, Tdolce constitution, and Tdolce present, all of which contain

Tdolce time mereology. DOLCE does not contain an ordering on time, but has a time mere- ology. In contrast, the PSL ontology uses timepoints to describe the temporal aspects of objects and activity occurrences, as well as uses an ordering on time, but does not con- tain a time mereology. From this observation, both ontologies appear to have intuitions of perdurants/endurants and activity occurrences/objects being present and participat- ing in some time construct. We explore these intuitions further by bridging these two ontologies together.

We note that Tdolce participation contains the following axiom (Ad35 in [51]) which indicates every endurant participates in some perdurant at a given time object:

x ED(x) (x, t) PC(y, x, t) ∀ ⊃ ∃

A similar axiom is found in Tpsl core that indicates activity occurrences require an object to participate in them. From these observations, we hypothesized that perdurants and

1As of writing, SUMO contains approximately 25,000 terms and 80,000 axioms [2], OpenCyc contains approximately 239,000 terms [18], whereas BFO is smaller in size [58]. 2SUMO, OpenCyc, and BFO are axiomatized in SUO-KIF, Lisp, and OWL, respectively. Chapter 4. Interpretations Between DOLCE & COLORE 71

endurants from DOLCE are equivalent to activity occurrences and objects in PSL, respec- tively. We can say that the notion of participation PC(x, y, z) in DOLCE is equivalent to the participates in(x, y, t) in PSL: for any object x, activity occurrence y, and time interval z, there exists a time construct t that is equivalent to the time interval z, where x participates in y during t. We write these equivalences as the following translation definitions: x P D(x) activity occurrence(x) (4.1.1) ∀ ≡

x ED(x) object(x) (4.1.2) ∀ ≡

x T (x) timeinterval(x) (4.1.3) ∀ ≡ x y z t (PC(x, y, z) ∀ ∀ ∀ ∀ ≡

object(x) activity occurrence(y) timeinterval(z) ∧ ∧ ∧

(beforeEq(beginof(z), t) beforeEq(t, endof(z)) participates in(x, y, t))). (4.1.4) ∧ ⊃

Based on these equivalences, we realized that there was a need to create new theories that combine and utilize timepoints and time intervals with the PSL ontology. In order to identify a concrete relationship between the two ontologies, we hypothesized that if we added a mereology of time intervals to PSL, or added an ordering to DOLCE, we would be able to determine whether theories from DOLCE could faithfully interpret theories found in PSL. Since PSL has a mereology and ordering on timepoints, but DOLCE only has a mereology on time intervals, we could not say that the theories between these ontologies are definably equivalent. In order to examine this interpretation of theories, a time ontology that contained both timepoints and time intervals was required in order to be strong enough to interpret a mereology on timepoints and time intervals. COLORE contains numerous mathematical theories that aided us in this regard: the Combined

Time hierarchy, Hcombined time, in COLORE contains time theories utilize both timepoint Chapter 4. Interpretations Between DOLCE & COLORE 72

and time interval constructs, and are able to interpret a mereology on timepoints and time intervals. Figure 4.1 illustrates how we bridged the PSL and DOLCE ontologies together, but we will first discuss the temporaly hierarchies in more detail below.

interval mandatory

dolce constitution mandatory psl core interval psl core dolce temporary parthood Interval PSL Hierarchy psl core root dolce participation PSL Hierarchy

dolce dependence dolce present endpoints interval with endpoints

dolce mereology dolce time mereology sim vc end

finite sim vc end dolce taxonomy Combined Time Hierarchy DOLCE Hierarchies finite periods

cem periods periods linear point lp infinite end

periods root lp ordering Periods Hierarchy Timepoints Hierarchy Figure 4.1: Relationships between DOLCE modules and theories in COLORE. Solid lines indicate conservative extensions, dashed lines indicate non-conservative extensions, and the bolded dash-dot-dotted lines indicate faithful interpretations between theories.

4.2 Temporal Theories in COLORE

Existing temporal theories found in COLORE were utilized to analyze the interpretations between the DOLCE and COLORE theories in this chapter. Here we briefly outline the timepoint and time interval theories used. We make a note here regarding the convexity of Chapter 4. Interpretations Between DOLCE & COLORE 73

time intervals in DOLCE. Intuitively, convex intervals are those which have no gaps [49]3. The convexity of time intervals requires an ordering over time intervals and a mereology. However, we reiterate that DOLCE only has a mereology over its time intervals, so it cannot define convexity.

4.2.1 The Timepoints Hierarchy (Htimepoints)

Within this hierarchy are theories that describe time in terms of timepoints. We were

interested in the in the weakest theory of this hierarchy, Tlinear point, since it is used by

Tendpoints which is described in Section 4.2.3, and Tlp infinite end.

4 The linear point theory, Tlinear point , derived from axioms found in [35], is a simple ontology representing timepoints on a line. It contains a binary relation, before(x, y), that is transitive and irreflexive, and axioms that state that timepoints infinitely extend a timeline in both forward and backward directions.

5 The linear timepoints with endpoints at infinity theory, Tlp infinite end , derived from axioms found in [35], is a simple ontology representing timepoints on a line. It contains axioms that infinitely extend a timeline in both forward and backward directions, and that there exist endpoints at infinity in both directions.

4.2.2 The Periods Hierarchy (Hperiods)

The axioms for the periods hierarchy, Hperiods, were provided in [62]; additional informa- tion about other theories in this hierarchy can be found in [29]. We were interested in

the in the weakest theory of this hierarchy, Tperiods, since it is used by Tendpoints, which is described in Section 4.2.3. 3Additional information about the various relations found in convex and non-convex intervals can be found in [49] and [45]. 4http://code.google.com/p/colore/source/browse/trunk/ontologies/ timepoints/linear_point.clif 5http://code.google.com/p/colore/source/browse/trunk/ontologies/ timepoints/lp_infinite_end.clif Chapter 4. Interpretations Between DOLCE & COLORE 74

The Minimal Theory of Periods, Tperiods, constitutes the minimal set of conditions that must be met by any period structure [62]. It contains two relations, precedence(x, y) and inclusion(x, y), and two conservative definitions, glb(x, y, z) and overlaps(x, y), as its non-logical lexicon. Every element in the domain is considered a time interval, and there are transitivity and irreflexivity axioms for the precedence(x, y) relation, making it a strict partial order; similarly, the transitivity, reflexivity, and anti-symmetry axioms for the inclusion(x, y) relation make it a partial order. As well, the axiom, glb(x, y, z), guarantees the existence of greatest lower bounds between overlapping intervals defined by overlaps(x, y).

4.2.3 The Combined Time Hierarchy (Hcombined time)

Hybrid-time theories are those that include both timepoints and time intervals as prim- itives, and define a set of functions and relations specifying the interactions between them. These time theories in COLORE are derived from the time ontologies presented in [35], and have been modified and verified in [32]; Figure 4.2 below shows the rela- tionships between all of the theories in this hierarchy. Depending on the relations and functions used, these theories can represent time in very different ways. For example, the

theory of endpoints, Tendpoints, defines timepoints only as the boundary of time intervals, where every interval is associated with exactly two timepoints: the begin of and end

of the interval. In contrast, the theory of timepoint continuum, Tpoint continuum, defines intervals by the set of adjacent timepoints in which they are contained; another theory,

Tvector continuum introduces the concept of directionality by allowing ‘backward intervals’ where the end of point is before the begin of point in the timeline. With such varied models for each hybrid-time theory, we briefly discuss them individually below, and refer the reader to [32] and COLORE6 for the axiomatizations of these theories.

6http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_ time/ Chapter 4. Interpretations Between DOLCE & COLORE 75 backwards nite_vc fi nite_backwards vectorcontinuum moment fi nite_moment mo_continuum fi nite_mo_continuum fi sim_vc_end nite_sim_vc_end fi mo_endpoints nite_no_moment nite_mo_endpoints fi fi no_moment endpoints nite_endpoints fi nite_no_backwards fi no_backwards interval_with_endpoints moment_with_endpoints nite_end lp_infi lp_ordering linear_point

Figure 4.2: Relationships between theories found in the Combined Time hierarchy, Hcombined time. Solid lines indicate conservative extensions and dashed lines indicate non- conservative extensions. Chapter 4. Interpretations Between DOLCE & COLORE 76

7 The theory of endpoints, Tendpoints , combines the language of intervals and points by defining the beginof, endof, and between functions to relate intervals to timepoints and

vice-versa. From Figure 4.2, we see that this theory imports axioms from Tlinear point that define a binary before(x, y) relation between timepoints as transitive and irreflexive, and asserts that all timepoints are linearly ordered and infinite in both directions. As well, this theory includes axioms that define the meets at(i, x, j) relation as one between two intervals and the point at which they meet along, restrict beginof(i) to always come before the endof(i) function, and states that intervals are between two points if they are properly ordered.

8 The vector continuum theory, Tvector continuum , introduces the notion of orientation of

intervals, and also imports Tlinear point. It contains the same three functions (beginof(i), endof(i), and between(x, y)) that transform intervals into timepoints and vice-versa, but differs in its definition of between(x, y) by allowing the formation of intervals whose

endof point is equal to or before its beginof. Thus, every interval in Tvector continuum has a ‘reflection’ in the opposite direction via the back(i) function; intervals oriented in the forward direction are defined normally where beginof(i) is before endof(i). As well, single-point intervals, known as moments, are defined as intervals whose beginof(i) and endof(i) points are the same.

9 In this work, we utilized the theory of similarity of vector continuums Tsim vc end .

Similar to Tvector continuum, this theory contains axioms that define the notion of orienta- tion of intervals, but also contains an axiom that describes the notion of similarity, as adopted from [32]:

Definition 4.2.1 Let T1 and T2 be theories with the language . The similarity of T1 L and T2 is the strongest subtheory of T1 and T2, so that for all σ, φ if T1 = σ and ∈ L | 7http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_ time/endpoints.clif 8http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_ time/vector_continuum.clif 9http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_ time/sim_vc_end.clif Chapter 4. Interpretations Between DOLCE & COLORE 77

T2 = φ, and T = σ and T = φ, then either σ φ is independent of T or it is a tautology. | 6| 6| ∨

This theory is used to examine the relationships between Tendpoints and Tvector continuum since both theories have the same primitive non-logical lexicon, and can be compared using the notions of satisfiability, extension, and independence [32].

4.2.4 Composing the Theory of Intervals with Endpoints

(Tinterval with endpoints)

The Combined Time hierarchy contains theories that relate timepoints and time intervals together. These theories were originally proposed by Pat Hayes in [35], and assume an import of the Tendpoints theory, where every time interval is associated with two timepoints.

However, since Tpsl core contains a timepoint ontology that contains a linear ordering with

10 endpoints at infinity , the theory becomes inconsistent with Tendpoints since time intervals cannot be described with this temporal theory. Consequently, we needed to remove the

time ontology from Tpsl core and specify a new time theory, Tinterval with endpoints, to make

combined time Tpsl core compatible with time intervals. In H , we created Tinterval with endpoints

to contain the time interval axioms of Tendpoints with a different timepoint ontology.

This new Intervals with Endpoints theory, Tinterval with endpoints, imports axioms from

combined time timepoints Tfinite sim vc end from H and Tlp infinite end from H . The primary dif-

combined time ference between the Tfinite sim vc end and Tsim vc end theories within H is that different timepoint ontologies are used in each theory; while both theories have a com-

mon theory, Tlp ordering, additional axioms in Tlinear point make Tsim vc end different from

Tfinite sim vc end, as depicted in Figure 4.1. Consequently, Tinterval with endpoints non-conservatively

extends Tfinite sim vc end since it contains the same time interval axioms as Tfinite sim vc end,

but different timepoint axioms from Tlp infinite end. The axioms of Tinterval with endpoints can be found in COLORE11. 10Refer to Axioms A.1.6 to A.1.9 in Appendix A.1.1. 11http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_ time/interval_with_endpoints.clif Chapter 4. Interpretations Between DOLCE & COLORE 78

The DOLCE ontology has no ordering on time intervals, but a mereology; combined time theories have an explicit ordering over time intervals and a mereology can be defined on them. The Periods hierarchy bridges DOLCE and combined time hierarchies together since Tperiods is the common theory between them. We note that the dash-dot-dotted arrows in Figure 4.1 outline the faithful interpretations between Hdolce and Hperiods, and Hperiods and Hcombined time; however, these are faithful interpretations are proposed and proofs have not been carried out12. We only discuss the composition of theories needed to prove the faithful interpretations between DOLCE and PSL.

4.3 Extending Tpsl core

Within PSL, activity occurrences are considered to be occurrents, while objects are rep- resented by continuants [22]. The relation participates in(x, o, t) is used to specify that an object x participates in activity occurrence o at timepoint t. Since DOLCE does not

13 utilize timepoints but time intervals in its time mereology, an extension of Tpsl core was created in order to utilize the participates in(x, o, t) relation with time intervals.

4.3.1 Theory of PSL-Core Root (Tpsl core root)

Furthermore, a subset of the axioms in Tpsl core were extracted to create the Tpsl core root

theory. The following closure axiom from Tpsl core was removed because it was too strong and contained the timepoint(x) construct:

( x (activity(x) activity occurrence(x) timepoint(x) object(x))). ∀ ∨ ∨ ∨

This theory is later used in the Interval PSL hierarchy( Hinterval psl), which is described in the next section. 12These will be addressed in future work. 13 We could not modify the axioms found in Tpsl core since the axioms are standardized in ISO 18629- 11:2005. Chapter 4. Interpretations Between DOLCE & COLORE 79

( x (object(x) ( o t participates in(x, o, t)))). (4.3.1) ∀ ⊃ ∃ ∃

( o t (activity occurrence(o) is occurring at(o, t) ∀ ∀ ∧ ⊃ ( x participates in(x, o, t)))). (4.3.2) ∃

Figure 4.3: Axioms found in Tmandatory.

4.3.2 Theory of Mandatory Participation (Tmandatory)

We defined a new non-conservative extension of Tpsl core called Tmandatory to take into account the mandatory participation of PSL objects in a temporal construct. In this extension, we did not commit to a specific temporal object, so t may be timepoints or

time intervals. The axioms found in this extension import Tpsl core root and do not include

the between(x, y, z) and before(x, y, z) relations found in Tpsl core since they involve the usage of timepoints, not time intervals, to describe the participation of objects in activity

occurrences and time objects. Figure 4.3 lists all of the axioms found in Tmandatory, and the axioms can be found in COLORE14. Axiom 4.3.1 indicates that every object x has to participate in some activity occurrence o at a time object t, and Axiom 4.3.2 indicates that, for every activity occurrence o that occurs during the time object t, there exists an object that also participates in that time object.

mandatory psl core

psl core root PSL Hierarchy Figure 4.4: Relationships between theories found in the PSL hierarchy. Solid arrows denote conservative extensions and dashed arrows denote non-conservative extensions.

14http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_core/ mandatory.clif Chapter 4. Interpretations Between DOLCE & COLORE 80

In Tmandatory, we did not commit to a specific type of temporal object for object participation, but we did note that there needs to be a ‘bridge’ of sorts to connect the DOLCE and PSL ontologies together. Consequently, we were interested in creating a new bridge ontology that contains the PSL constructs that are used with time intervals.

We discuss this new Hinterval psl hierarchy in the next section.

4.4 The Interval PSL Hierarchy (Hinterval psl)

Since the PSL ontology only describes object and activity occurrences with respect to timepoints, we needed to create a time interval version of the PSL ontology. A new

interval psl hierarchy, H , was created in COLORE with Tinterval psl core as its root theory.

This hierarchy contains the time interval versions of the Tpsl core and Tmandatory theo- ries which are named Tinterval psl core and Tinterval mandatory, respectively, and are depicted in Figure 4.7. Each of these theories is briefly described below, and can be found in COLORE15.

4.4.1 Theory of PSL-Core with Intervals (Tinterval psl core)

This theory imports axioms from Tpsl core root and Tinterval with endpoints. In order to ensure

that the time interval version of Tpsl core root contains axioms that describe time intervals,

and not timepoints Tinterval with endpoints is used to describe the time objects found in this compiled theory.

Three axioms are added to Tinterval psl core in addition to the imported theories and are outlined in Figure 4.5. Axiom 4.4.1 indicates that a time interval is not an activity, activity occurrence, object, or timepoint. In Axiom 4.4.2, the relation, psl interval(x, y), is introduced to relate a time interval with the begin of and end of an activity occurrence or object. Finally, the overlay(x, y, z) relation is introduced in Axiom 4.4.3 to describe

15http://code.google.com/p/colore/source/browse/trunk/ontologies/interval_ psl Chapter 4. Interpretations Between DOLCE & COLORE 81

( x (timeinterval(x) (activity(x) activity occurrence∀ (x) timepoint⊃ (x) object(x)))). (4.4.1) ¬ ∨ ∨ ∨

( x y (psl interval(x, y) ∀ ∀ ≡ (activity occurrence(x) object(x)) timeinterval(y) beginof(x) = beginof∨(y) endof(∧x) = endof(y))). ∧ (4.4.2) ∧

( x y z (overlay(x, y, z) ∀ ∀ ∀ ≡ ( i1 i2 (psl interval(x, i1) psl interval(y, i2) ∃ ∃ ∧ ∧ beginof(i2) = beginof(z) endof(i1) = endof(z))))). (4.4.3) ∧

Figure 4.5: Axioms of Tinterval psl core.

a time interval z that overlays16 activity occurrences x and y. However, it may not necessarily be the case that both activity occurrence/object y overlays an activity occur- rence/object x, or vice versa. This axiom is included in case such overlaying of intervals does occur. Figure 4.6 graphically depicts this relationship between two overlaying time intervals.

i1 x

i2 y

z

Figure 4.6: Graphical depiction of the overlay(x, y, z) relation.

16We chose not to use the terms overlap and intersect because they are used in mereology ontologies. To be consistent with PSL, we decided to use the term overlay to describe the relationship where time intervals may overlay one another. Chapter 4. Interpretations Between DOLCE & COLORE 82

4.4.2 Theory of Mandatory Intervals (Tinterval mandatory)

Finally, we have the theory of mandatory intervals which imports axioms from Tinterval psl core

and Tmandatory. Since we would like to show that Tdolce participation can faithfully interpret the time interval versions of PSL theories from Tinterval psl core, we extended Tinterval psl core

to include the time interval versions of the axioms from Tmandatory. No additional axioms are included in this theory and it can be found in COLORE17. Essentially this theory

18 assigns time intervals to Tinterval psl core to indicate the mandatory participation of PSL over a time interval. Figure 4.7 summarizes the relationships between the Interval PSL, PSL, and Combined Time hierarchies.

4.5 Interpretations Between DOLCE and Theories

in COLORE

In order to determine whether DOLCE theories are able to faithfully interpret the theories

in COLORE, we needed to modify Tdolce present. To preserve the original DOLCE axioms,

a copy of Tdolce present was created with all references of qualities Q(x) removed and

this new theory was named as Tdolce present . This is due to the fact that Tpsl core root is ∗ unable to define what a quality is due to the following translation definitions used in our verification: x ED(x) object(x) ∀ ≡

x Q(x) object(x) ∀ ≡

Since Tpsl core root is unable to discern which object(x) is an endurant ED(x) or a quality

Q(x), it was necessary to create a subtheory of Tdolce present that did not include qualities

for this portion of the interpretation. The axioms of Tdolce present can be found in Ap- ∗ 17http://code.google.com/p/colore/source/browse/trunk/ontologies/interval_ psl/interval_mandatory.clif 18 Recall that we did not commit to a particular temporal construct in Tmandatory. Chapter 4. Interpretations Between DOLCE & COLORE 83

Interval PSL Hierarchy interval mandatory

interval psl core mandatory psl core

psl core root PSL Hierarchy

interval with endpoints

finite sim vc end

Combined Time Hierarchy Figure 4.7: Relationships between the Interval PSL, PSL, and Combined Time hier- archies. Solid lines indicate conservative extensions and dashed lines indicate non- conservative extensions between theories. Chapter 4. Interpretations Between DOLCE & COLORE 84

19 pendix B.2.1 and in COLORE . This creation of Tdolce present does not affect any of the ∗ modules verified in the previous chapter since the modularization of DOLCE includes the quality axioms.

The DOLCE theories for Tdolce participation and Tdolce time mereology are able to interpret

interval psl the Tinterval mandatory and Tinterval psl core theories in H , respectively. Figure 4.8

illustrates these graphically, where ∆1 and ∆2 are interpretations from the DOLCE theories to the Interval PSL theories. We discuss each interpretation below.

Interval PSL Hierarchy

∆2 interval mandatory dolce participation

dolce present

∆1 dolce present* interval psl core

dolce time mereology

dolce taxonomy

DOLCE Hierarchy Figure 4.8: Interpretations between DOLCE modules and theories in COLORE. Solid lines indicate conservative extensions, dashed lines indicate non-conservative extensions, and the bolded dash-dot-dotted lines indicate faithful interpretations between theories.

4.5.1 Interpretations Between T and T interval psl core dolce present∗ From our brief discussion of the theories found in COLORE, we make the observation that the concept of parthood in DOLCE is equivalent to the inclusion of time intervals 19http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ present/dolce_present_star.clif Chapter 4. Interpretations Between DOLCE & COLORE 85

in Tinterval psl core:

( t1 t2 (P (t1, t2) ∀ ∀ ≡

timeinterval(t1) timeinterval(t2) ∧ ∧

beforeEq(beginof(t2), beginof(t1)) beforeEq(endof(t1), endof(t2)))). (4.5.1) ∧

We graphically depict this relationship in Figure 4.9; the time interval t1 is part of time interval t2: the beginning of t2 can either be before or equal to the beginning of t1, and the end of t1 can either be before or equal to the end of t2.

t2

t1

Figure 4.9: Graphical depiction of the P (x, y) translation definition for Tinterval psl core and Tdolce present . ∗

Furthermore, we can state that the concept of being present in DOLCE is equivalent to the concept of an object or activity occurrence that exists in a given time interval, where the beginning of the time interval is the timepoint in which an object or activity occurrence starts, and that the end of the time interval is the timepoint in which the object or activity occurrence ends.

( x y t (PRE(x, t) ∀ ∀ ∀ ≡

(object(x) activity occurrence(x)) timeinterval(t) ∨ ∧ ∧ beforeEq(beginof(x), beginof(t)) beforeEq(endof(t), endof(x)))). (4.5.2) ∧ We note that, in psl interval(x, y), an unique maximal time interval is associated with an object or activity occurrence in PSL. On the other hand, the time interval associated in PRE(x, t) in DOLCE needs not be the maximal interval at which an endurant or perdurant is present. Thus, we define that a time interval z is the sum of the time Chapter 4. Interpretations Between DOLCE & COLORE 86

intervals of two activity occurrences x and y as follows:

x y z(SUM(z, x, y) (timeinterval(x) timeinterval(y) timeinterval(z) ∀ ∀ ∀ ≡ ∧ ∧ ∧

(((beginof(z) = beginof(x)) (endof(z) = endof(y))) ∧ ∨ ((beginof(z) = beginof(y)) (endof(z) = endof(x)))))). (4.5.3) ∧ Consequently, the translation definition for SUM(z, x, y) reflects the idea that the sum of two time intervals in DOLCE can be the minimal sum or the maximal sum, as depicted in Figure 4.10.

i1 x

i2 y

z minimal sum of intervals z maximal sum of intervals Figure 4.10: Graphical depiction of the SUM(z, x, y) translation definition.

Theorem 4.5.1 Tinterval psl core interprets Tdolce present . ∗

Proof Let ∆1 be the set of translation definitions

x((ED(x) object(x))). ∀ ≡ x((Q(x) object(x))). ∀ ≡ x((PD(x) activity occurrence(x))). ∀ ≡ x((T (x) timeinterval(x))). ∀ ≡

t1 t2((P (t1, t2) timeinterval(t1) timeinterval(t2) ∀ ∀ ≡ ∧ ∧ beforeEq(beginof(t2), beginof(t1)) beforeEq(endof(t1), endof(t2)))). ∧

x y t(PRE(x, t) ((object(x) activity occurrence(x)) ∀ ∀ ∀ ≡ ∨ ∧ Chapter 4. Interpretations Between DOLCE & COLORE 87

timeinterval(t) beforeEq(beginof(x), beginof(t)) ∧ ∧ beforeEq(endof(t), endof(x)))).

x y z(SUM(z, x, y) (timeinterval(x) timeinterval(y) timeinterval(z) ∀ ∀ ∀ ≡ ∧ ∧ ∧ (((beginof(z) = beginof(x)) (endof(z) = endof(y))) ∧ ∨ ((beginof(z) = beginof(y)) (endof(z) = endof(x)))))). ∧

Tinterval psl core ∆1 = Tdolce present ∪ | 

Thus, we can say that Tinterval psl core faithfully interprets Tdolce present. The proofs for these experiments can be found in COLORE20.

4.5.2 Interpretations Between Tinterval mandatory and Tdolce participation

For the interpretation of Tinterval mandatory and Tdolce participation, we reuse the set of trans- lation definitions, ∆1, from the previous section, along with the additional translation definition described below. ∆1 is reused because Tinterval mandatory imports Tinterval psl core,

so ∆1 is used in conjunction with ∆2. Since the DOLCE ontology contains axioms for participation21, we make the observa- tion that the participation relation, PC(x, y, z), is similar to the participates in(x, y, t) relation found in PSL. Thus, we can state that any x and y that participate in z in DOLCE is equivalent an object x that participates in an activity occurrence y in a given time interval z and, at every timepoint in that interval, x participates in y.

( x y z t (PC(x, y, z) ∀ ∀ ∀ ∀ ≡ 20http://code.google.com/p/colore/source/browse/svn/trunk/ontologies/ dolce_present/interprets/output 21Recall that our verification of DOLCE is a partial modularization of the ontology. The modules of our verification were presented in Chapter3, but we did not include Tdolce participation, so it will be verified in future work. Chapter 4. Interpretations Between DOLCE & COLORE 88

object(x) activity occurrence(y) timeinterval(z) ∧ ∧ ∧

(beforeEq(beginof(z), t) beforeEq(t, endof(z)) participates in(x, y, t)))). (4.5.4) ∧ ⊃

Theorem 4.5.2 Tinterval mandatory interprets Tdolce participation.

Proof Let ∆2 be the set of translation definitions

x y z t((PC(x, y, z) object(x) activity occurrence(x) ∀ ∀ ∀ ∀ ≡ ∧ ∧ timeinterval(z) beforeEq(beginof(z), t) ∧ ∧ beforeEq(t, endof(z)) participates in(x, y, t)))). ⊃

Tinterval mandatory ∆1 ∆2 = Tdolce participation ∪ ∪ | 

Thus, we can say that Tinterval mandatory faithfully interprets Tdolce participation. The proofs for these experiments can be found in COLORE22.

4.6 Insights

Faithful interpretations between the DOLCE and COLORE theories in this chapter have shown that there multiple ‘bridges’ were needed before any analyses with the

Tdolce participation and Tdolce present theories could be carried out with theories in COLORE. Firstly, we saw that the Combined Time hierarchy bridges the Periods and Timepoints hierarchies together to have ontologies of time that contain both timepoints and time intervals. Secondly, the Interval PSL hierarchy bridges both the PSL and DOLCE hier- archies together to allow the faithful interpretations of mereology and orderings in both timepoints and time intervals. This exercise in bridging ontologies together proves to be rewarding since it demonstrates how we can axiomatize the relationships between theories and outline the composition of theories that are required for the bridging task.

22http://code.google.com/p/colore/source/browse/svn/trunk/ontologies/ dolce_participation/interprets/output Chapter 5

Semantic Augmentation: The CIMOSA Process Ontology

In this chapter, we outline a case study where semantic augmentation is required to provide an ontology with semantics. With Enterprise Modelling (EM) formalisms, there currently do not exist ontologies that explicitly define the terms utilized in their syn- tactic constructs. An ontology is a formal specification of the knowledge, concepts, and relationships found within a domain. Without such specifications in EM languages, it makes it difficult for users of the language to understand how the constructs can be used. With an explicit definition of these terms, users and software applications will then be able to use the constructs correctly and appropriately.

5.1 Background & Motivation

Enterprises & Ontologies

During the mid 1990s, enterprise modelling (EM), enterprise engineering (EE), and en- terprise integration (EI) had become a focal point in the manufacturing industry. The overall goal of enterprise modelling is to better understand, represent, and design enter-

89 Chapter 5. The CIMOSA Process Ontology 90

prise operations [63], and is considered the first step to achieving enterprise integration. Enterprise engineering, on the other hand, is concerned with (re)designing business enti- ties that are involved in an enterprise’s lifecycle to optimize the cost, time, and resource aspects of the enterprise [63]. Finally, the goal of enterprise integration is to break down any organizational barriers within the enterprise, such as humans, machines, and appli- cations, to facilitate improved communication, co-operation, and co-ordination [63, 61]. Consequently, the interest in these three aspects of enterprises has led the way for enterprise ontologies to be introduced and applied in practice. An enterprise ontology is a collection of terms and definitions that are relevant to business enterprises [61]. Intended to be sets of terms and definitions that adequately and correctly covers concepts found in the enterprise domain, the Edinburgh Enterprise and TOronto Virtual Enterprise (TOVE) ontologies described in [61] and [31], respectively, are intended to resolve any misunderstandings where terms are used differently. Acting as a communication medium between people and computational system, the Edinburgh Enterprise Ontology (EEO) assists users with the representation of basic and core enterprise concepts, along with structuring and organizing libraries of knowledge [61]. As such, it outlines five different classes for describing the various aspects of an enterprise (Activities and Processes, Organization, Strategy, Marketing, and Time). Activities and Processes consist of the activities and resources in the enterprise, while the Organization class covers the organizational constraints for the enterprise. Similarly, the Strategy class contains all of the goals, policies, and relationships to the activities performed by the enterprise and its agents. The Marketing class covers the external relationships between the enterprise, its customers, suppliers, and partners. The EEO does not, however, cover nor describe an enterprise’s products and services in detail. The TOVE project is an integrated suite of ontologies that is designed to provided a shared terminology for the enterprise that can be jointly understood and used by appli- cations [17, 31]. The suite is divided into three groups: Core, Derivative, and Enterprise Chapter 5. The CIMOSA Process Ontology 91

ontologies. The Core ontologies capture the generic characteristics of an enterprise, while the Derivative ontologies are specializations of classes found in the Core category. From there, the Enterprise ontologies are used to define classes of enterprises through the identification of classes of processes, resources, products, services, and organization constraints found in enterprises. With this in mind, ontologies for enterprise modelling formalisms have not been es- tablished to alleviate any of the previously discussed communication barriers. We have chosen to study and develop a process ontology the CIMOSA framework, which will be further discussed in Section 5.2.

The Process Specification Language (PSL)

Since we have already described PSL in Section 2.1.5, we remind the reader that PSL contains axioms that have been well-defined and standardized in ISO 18629-1:2004, so it was appropriate to utilize this ontology to semantically augment CIMOSA concepts.

IAOA’s Standardization Coordination Efforts

Within the International Association of Ontology and its Applications (IAOA), the Stan- dardization Coordination Committee fosters the harmonization between the ontology and standards communities. As well, the committee works with the Ontology Integration and Interoperability (OntoIOp) group to facilitate the application of ontologies and ontolog- ical analysis to existing and emerging standards. Currently, the committee is looking into methodologies for evaluating standards ontologically to assist people in developing and evaluating standards. Consequently, this work aids the committee in their interest to ontologically evaluate a semantically-weak standard such as CIMOSA. Chapter 5. The CIMOSA Process Ontology 92

5.2 The Computer Integrated Manufacturing Open

System Architecture (CIMOSA)

The focus of this case study was to examine the Computer Integrated Manufacturing Open System Architecture (CIMOSA), which was developed in 1992 and has been stan- dardized by the International Organization for Standardization (ISO) since 2006. Its construct specification can be found in [39] and [40], which forms the basis of the work done in this case study. ISO 19439:2006 and ISO 19440:2007 define generic concepts that are used in enterprise models and frameworks with the intention of being integrated in computer (manufacturing) systems. CIMOSA defines an integrated methodology to sup- port all phases of a CIM system life cycle from the requirements specification through to the system design, implementation, operation, and maintenance phases [17]. This methodology is used to plan, design, and optimize the environment in which the enter- prise operates. Furthermore, CIMOSA provides industry with an enterprise modelling framework (EMF) and an integrating infrastructure (IIS) [46, 63]. The modelling framework repre- sents the business operations in the form of processes and allows the creation of executable enterprise models in CIM programs. The IIS is used to support the integration of busi- ness and applications, as well as the execution and implementation of models to control and monitor enterprise operations. This infrastructure provides a set of generic services that process the implementation model, provide access to information, and connect to resources. For the purposes of this case study, only the modelling framework will be discussed in detail in the sections that follow.

CIMOSA Modelling Framework

The CIMOSA modelling framework supports the explicit description of enterprise pro- cesses at different levels of abstraction. The CIMOSA cube shown in Figure 5.1 outlines Chapter 5. The CIMOSA Process Ontology 93

the ability to model different aspects and views of an enterprise. This three-dimensional framework has the following dimensions: Dimension of genericity: the degree of particularization that spans generic building • blocks to their aggregation into a model of a specific enterprise domain, Dimension of modelling: provides the modelling support for the system life cycle, • starting from statements of requirements to a description of the system implemen- tation, Dimension of views: offers the possibility to work with sub-models representing • different aspects of the enterprise.

Figure 5.1: The CIMOSA modelling approach, adapted from Figure 1 in [46].

Dimension of Genericity

CIMOSA categorizes manufacturing operations with respect to Generic and Specific (Partial and Particular) functions. Generic functions are found in Reference Archi- tectures, and can be considered to be a catalogue of reusable building blocks that are applicable to specific needs in an enterprise. Particular Architectures serves the use of specific cases in process modelling which are not intended to be reusable for other models (hence the name ‘partial’ and ‘particular’). Chapter 5. The CIMOSA Process Ontology 94

Dimension of Modelling

CIMOSA facilitates a system life cycle which guides the user through model engineering and model execution. The life cycle does not represent a time sequence, but identifies a set of activities, which may be carried out in any sequence appropriate for the particular enterprise engineering tasks at hand [46]. The life cycle consists of collecting business requirements (Requirements Definition), translating the requirements into a model, and developing a description of the CIM system (Design Specification). These phases are followed by the implementation of the model for controlling and monitoring purposes (Implementation Description).

Dimension of Views

To model the specific aspects of the enterprise, CIMOSA defines four different views of the enterprise which are described below.

1. Function View: describes the work flows required to satisfy the enterprise’s objec- tives.

2. Information View: describes the inputs and outputs required by each function.

3. Resource View: describes the structure of resources (humans, machines, informa- tion systems) and how they relate to functional and control aspects of the enterprise.

4. Organization View: describes and defines the responsibilities assigned to individu- als.

Types of Flows

In addition to the modelling views, three separate types of flows within an enterprise are identified in CIMOSA[63]:

The control flow is a work flow and describes the enterprise behaviour • The material flow describes the flow of products and physical components • The information flow describes the flow of information objects and decisions • Chapter 5. The CIMOSA Process Ontology 95

Basic CIMOSA Constructs

In addition to the modelling framework, the CIMOSA Reference Architecture provides a basic set of building blocks for modelling enterprises [47]: Processes, Events, and Enterprise Activities are object classes that describe the • functionality and behaviours of the enterprise’s operations.

Inputs and outputs of Enterprise Activities define the information (Enterprise Ob- • ject) and the resources needed.

Organizational aspects of the enterprise are defined in terms of responsibilities and • authorisation (Organization Elements) for functionalities, information, resources and organization, and are structured into Organisational Units or Cells.

These constructs are graphically outlined in Figure 5.2.

Figure 5.2: The CIMOSA modelling constructs, adapted from Figure 2 in [47].

Process-Based Enterprise Modelling

The CIMOSA modelling paradigm is based on an event-driven process-based modelling approach. CIMOSA distinguishes between processes and resources as the things to be done and the doers of the activities, respectively. A business process is a collection of related activities or tasks defined by the business to fulfil some goals of the enterprise and/or customer. Chapter 5. The CIMOSA Process Ontology 96

In the context of CIMOSA, business processes are defined in terms of the work flow required by the enterprise, where enterprise activities are elementary steps in a process. As outlined in [39] and [40], business processes can be further decomposed into constituent business processes or enterprise activities, or both, along with their interconnections, and can be arranged by ordering relationships and dependencies that are described by behavioural rules [39, 40]. Behavioural rules describe the logical sequence of relationships found within enterprise activities, and identify the start of the business process [39, 40]. Logical sequencing of processes outlined in [40] consists of:

Well-structured processes: the sequence of business processes or enterprise activities • are completely defined (deterministic), and the expected outcome is known.

Semi-structured processes: the sequence of business processes or enterprise activ- • ities is only known at run-time (semi-deterministic), and the expected outcome is known.

Ill-structured processes: the sequence of business processes and the expected out- • come are not completely known (non-deterministic).

In CIMOSA, behavioural rules have the following form:

WHEN (condition) DO action

Several work flow situations that may occur and its language syntax, in Backus-Naur form, are presented in [63]. The behavioural rules are summarized in Table 5.1, and the language syntax for CIMOSA’s Behavioural Rule Set (BRS) is shown below.

Grammar 5.1: Behavioural Rule Set (BRS) for well-structured processes specified in Backus-Naur Form in [63]. behavioural r u l e s e t ::= ::= ::= WHEN (START) DO ::= ::= n i l Chapter 5. The CIMOSA Process Ontology 97

::= WHEN ( ) DO ::= START WITH ::= event id ::= AND event− id n i l ::= < n e x t behavioural r u l e s > ::= n i l ::= WHEN ( ) DO < action > ::= < n e x t t r i g g e r i n g c o n d i t i o n > ::= AND < n e x t t r i g g e r i n g c o n d i t i o n > AND event id n i l ::= ES ( process s t e p id ) = ::= ending status id ANY − ::= process −step id− < synchronous spawning− > −FINISH ::= process step id ::= & process step id− n i l ::=− SYNC− ( )

The condition part of the rule outlines the circumstances in which the next step in a process can be started; these include the occurrence of one or more events, end of a process step, or combination of these [63, 47,1]. The action part indicated the step that is activated next when the condition part becomes true. If one or more steps need to be performed in parallel, the ‘&’ operator is used. The flow of control in a process is determined by state changes and transitions. It is of great interest to axiomatize these behavioural rules as first-order sentences by using axiomatized concepts, such as objects, activities, subactivities, activity occurrences, and participation, from PSL. Each of these behavioural rules are further discussed in the sections that follow. Chapter 5. The CIMOSA Process Ontology 98

Table 5.1: CIMOSA behavioural rules, adapted from [63] and [1].

Type Syntax WHEN (START WITH event 1) Process Triggering Rules DO EF1 Forced Sequential Rules WHEN (ES(EF1)=any) DO EF2 Sequential Rules WHEN (ES(EF1)=end stat 1) DO EF1 WHEN (ES(EF1)=end stat 1) DO EF2 Conditional Sequential Rules WHEN (ES(EF2)=end stat 2) DO EF3 WHEN (ES(EF3)=end stat 3) DO EF4 WHEN (ES(EF1)=value 1) Spawning Rules DO EF1 & EF2 & EF3 WHEN (ES(EF1)=value 1 AND ES(EF2) Rendezvous Rules (Logical AND) =value 2 AND ES(EF3)=value 3) DO EF4 WHEN (ES(EF1) = value 1 OR ES(EF2) = Convergence Rules (Logical OR) value 2 OR ES(EF3)=value 3) DO EF4 Loop Rules WHEN ES(EF1)=loop value DO EF1 Process Completion Rules WHEN ES(EF2)end stat 1 DO FINISH

Behavioural Rules for Well-Structured Processes

This section outlines the behavioural rules for deterministic processes that have expected outcomes.

Process Triggering Rules

Process triggering rules come in two forms:

Initiating a Business Process by calling one or more enterprise functions (EF s); for • example, event 1 and event 2):

WHEN (ST ART W IT H event 1 AND event 2) DOEF 1

Initiating one or more EF s following the occurrence of a designated start event: • WHEN (ST ART ) DOEF 1 Chapter 5. The CIMOSA Process Ontology 99

Forced Sequential Rules

These rules are used when a process step must follow another step regardless of the ending status of the previous step. In the example below, EF y follows EF x regardless of the ending status of EF x. The reserved word ANY is used by the author of [63] to illustrate the disregard for the ending status. They are of the form:

WHEN (ES(EF x) = ANY ) DO EF y

Conditional Sequential Rules

Unlike the forced sequential rules, these rules are used to represent branching conditions. These rules cause the activation of one of a defined number of Enterprise Activities or Business Processes according to the value of an ending status. For example, if EF 1 had three different ending statuses, we can write:

WHEN (ES(EF 1) = end stat 1) DOEF 2

WHEN (ES(EF 1) = end stat 2) DOEF 3

WHEN (ES(EF 1) = end stat 3) DOEF 4

This indicates that EF 2, EF 3, and EF 4 are the different branches that are enabled depending on the ending status of EF 1.

Spawning Rules

These rules are used to represent the parallel execution of process steps. Two types of spawning rules are defined in [63] and [40]:

Asynchronous spawning: For instance, when EF 1 finishes with status value, EF 2, • EF 3 and EF 4 will all be requested to start as soon as they are enabled, i.e. when Chapter 5. The CIMOSA Process Ontology 100

their preconditions are satisfied (& is the parallel operator).

WHEN (ES(EF 1) = value) DOEF 2 & EF 3 & EF 4

Synchronous spawning: For instance, when EF 1 finishes with status value, EF 2, • EF 3 and EF 4 will all be requested to start exactly at the same time assuming that they are all enabled (SYNC indicates the synchronisation).

WHEN (ES(EF 1) = value) DOSYNC (EF 2 & EF 3 & EF 4)

Rendezvous Rules

Rendezvous rules are used to synchronize the end of spawning rules. For example, if EF 5 starts after EF 2 finishes with a status of value 24, EF 3 finishes with a status of value 3, and EF 4 finishes with a status of value 4, then the rendezvous rule is written as: WHEN (ES(EF 2) = value 2 AND ES(EF 3) = value 3

AND ES(EF 4) = value 4) DOEF 5

Loop Rules

Loop rules repeat a process step (or several) as long as a given condition holds, or for a defined number of iterations. In the example below, EF 1 repeats until it continues to have a status of loop value.

WHEN (ES(EF 1) = loop value) DOEF 1

Process Completion Rules

Process completion rules indicate the end of an execution of a set of rules. In [63], a process behaviour is declared to be consistent if FINISH can be reached from all STARTs and all process steps used in the rules belong to at least one path from START Chapter 5. The CIMOSA Process Ontology 101

to FINISH (no isolated process steps and no dead-ends are allowed) in the control flow.

WHEN (ES(EF 1) = end stat x AND ES(EF 2) = end stat y) DOFINISH

Behavioural Rules for Semi-Structured Processes

In [63], two additional rules have been added to model semi-structured processes. In these rules the ‘action’ refers to a compound action, denoted by the set S, which indicates that it is considered as a whole in order to define its ending status. The exclusive choice, XOR, operator is used The grammar is defined as follows:

Grammar 5.2: Behavioural Rule Set (BRS) for semi-structured processes specified in Backus-Naur Form in [63]. ::= ::= compound action id = ( process step id XOR process step id ) − − ::= XOR process step id < o t h e r r u n t i m e s t e p s > n i l − − ::= compound action id = process step id , process −step id − − ::= process step id}< o t h e r u n o r d e r e d s e t s t e p s > n i l − −

Run-Time Choices Rules

These rules are used when there is an exclusive choice among several alternatives. Exactly one process step in the list will be executed as decided by the resource at run-time, which must be common to all steps in the list.

WHEN (ES(EF 1) = end stat 1) DOS = (EF 2 XOREF 3 XOREF 4) Chapter 5. The CIMOSA Process Ontology 102

Unordered Set Rules

They are used to indicate that a set of process steps must be executed, but the order of execution is unknown.

WHEN (ES(EF 1) = end stat 1) DOS = EF 2,EF 3,EF 4 { }

As a whole, CIMOSA defines a model-based enterprise engineering method that cat- egorizes manufacturing operations into generic and specific functions. These functions can be combined to create a model that can be used for simulation and analysis, schedul- ing, dispatching, monitoring, and providing process information. While [40] provides templates and behavioural rules for its constructs, it does not explicitly define, nor ax- iomatize, the CIMOSA terminology in a computer-interpretable manner.

5.3 Methodology

In order to axiomatize CIMOSA’s constructs and behavioural rules in first-order logic, various approaches were taken in order to understand the framework’s implicit semantics. The subsequent sections that follow outline the methodologies taken to axiomatize the concepts and behavioural rules found in CIMOSA, which include: Identifying competency questions that the ontology should answer. • Matching the syntactic grammar found in CIMOSA and PSL. • Identifying keywords to develop a lexicon of CIMOSA terminology. • Axiomatizing the behavioural rule set through identification of similar PSL con- • structs.

In summary, the ‘methodology’ taken is ad-hoc in nature: there was no real process with developing the axioms. Once the competency questions were identified, it was appropriate to try to utilize, as much as possible, the available materials on CIMOSA’s behavioural rule set. In this case, this involved attempting to match the syntactic grammars provided Chapter 5. The CIMOSA Process Ontology 103 in [63] and to develop a list of terminology used in [40] and [1]. Once matching the grammars proved to be difficult and unfruitful, we then attempted to develop axioms to describe the rules. Thus, there was no ‘real’ nor structured process taken to go from one step to another, so it would not be appropriate to depict the steps graphically in a flowchart.

5.3.1 Identification of Competency Questions

Competency questions are used to determine the scope of the ontology to be designed and are essentially questions that a knowledge base, based on the ontology, should answer [27]. Thus, these questions aid ontology designers in determining whether or not the ontology contains information to answer these types of questions, and whether a particular level of detail or representation is needed for the ontology. Since we have limited our scope to axiomatize only the CIMOSA behavioural rules, the competency questions have been restricted to ask process-related questions. As such, the following competency questions were developed to help guide the ontology design process:

1. Which enterprise function starts the domain process?

2. What ending status triggers the following enterprise function?

3. When does this enterprise function or domain process terminate?

4. Does this enterprise function repeat itself?

5. Are these enterprise functions done in parallel?

5.3.2 Utilizing CIMOSA’s Grammar

CIMOSA’s modelling constructs are outlined in Grammar 5.1 and can be used to examine the relationship between states and activities in PSL. By mapping the CIMOSA and PSL grammars for state-based activities, this allows the further examination of the CIMOSA behavioural rules and the discovery of any relationships between PSL and CIMOSA, such as the identification of corresponding activity classes between the two languages. Chapter 5. The CIMOSA Process Ontology 104

We examine the grammar found in the State-based Conditional Activity Axioms section of the PSL ontology1, which are given below.

Grammar 5.3: Grammar for process descriptions in PSL. (conditional ?a) < conditional a c t i v i t y > ::= (forall (?s ?s2) ( i f f (do ?a ? s ? s2 ) < s i m p l e conditional >))

( p a r t i a l conditional ?a) < p a r t i a l conditional > ::= (forall (?s ?s2 < v a r i a b l e >+) ( i f f (do ?a ? s ? s2 ) < conditional f o r m u l a >))

Grammar 5.4: Grammar for auxiliary rules in PSL. < s i m p l e conditional > ::= ( i f < s i m p l e s t a t e a x i o m > < v a r i a t i o n f o r m u l a >)

< conditional f o r m u l a > ::= ( i f < state axiom > < v a r i a t i o n f o r m u l a >)

Direct mappings between the grammars could not be determined, so it was decided to move onto the next method of identifying keywords found in [39], [40], and [1] to develop a lexicon for CIMOSA. In future revisions of the ontology, we will revisit this idea to match the grammars.

5.3.3 Identifying Keywords to Piece Together Behavioural Rules

Another approach taken was to identify the frequently used key terms in [39], [40], [1], and [63]. To this effect, a lexicon for CIMOSA was developed to capture process-related terminology used in the descriptions of CIMOSA’s behavioural rule set. By developing a lexicon, it provided a starting point for creating the ontology and allowed the distinction

1The grammar for the State-based Conditional Activity axioms in BNF form can be accessed via: http://www.mel.nist.gov/psl/psl-ontology/part42/grammars/state_ variation.bnf.html Chapter 5. The CIMOSA Process Ontology 105 between relations and functions needed to semantically augment the CIMOSA constructs with terminology from PSL. A lexicon is essentially the vocabulary of a language that contains some knowledge of how each word is used [38]. For technical domains, such as that in CIMOSA, if an explicit vocabulary of terms exist, then it is possible that an ontology exists within the vocabulary [38]. A lexicon that is structured with semantic hierarchies can serve as a basis for an ontology, and that an ontology gives way for lexical classifications. It remains debatable whether a lexicon is considered as an ontology2, but for the purposes of this case study, the development of a lexicon of terms was determined to be the best way to approach the ontology design process. A lexicon allowed the determination of terms that were potentially equivalent to concepts defined in the PSL lexicon found in [22]. By examining [39], [40], [1], and [63], key words that captured the intended the seman- tics of the CIMOSA framework were identified and are further discussed in Section 5.4.1. A drawback of this method to determine keywords is that not all of the keywords identi- fied were used in the axiomatizations with PSL constructs; this was due to the fact that some CIMOSA constructs could not be directly mapped with PSL constructs.

5.3.4 Axiomatizing the Behavioural Rule Set Through Identi-

fication of Similar PSL Constructs

Another approach taken was to axiomatize the behavioural rule set without any keywords, but to go straight ahead with identifying PSL constructs that could be used to represent the rules. Since CIMOSA’s process descriptions involve complex activities, we can utilize the constructs found in the PSL ontology to map CIMOSA expressions into sentences that contain these PSL constructs.

The constructs that are used are of those found in the PSL-CORE hierarchy Hpsl core 2Additional notes about the relationships between lexicons and ontologies can be found in [56], [5], and [64]. Chapter 5. The CIMOSA Process Ontology 106 in COLORE3. Activity trees characterize the occurrences of complex activities and con- sists of all possible sequences of atomic subactivity occurrences beginning from a root subactivity occurrence. Possible sequences of subactivity occurrences of the complex ac- tivity correspond to branches within the activity tree. The following relations are used to describe complex activities within PSL[21] and their axiomatizations can be found in Appendix C.1:

root(o, a) specifies that the atomic subactivity occurrence o is the root of the activity • tree.

leaf(s, a) specifies the leaf of an activity tree if and only if there exists an earlier • atomic subactivity occurrence but there does not exist a later atomic subactivity occurrence.

min precedes(s1, s2, a) is the ordering relation over the atomic subactivity occur- • rences in the activity tree.

precedes(o1, o2) specifies that o1 is earlier than o2 within the occurrence tree. •

The axiomatized behavioural rules can be found in Sections 5.4.2 and 5.4.3.

5.4 The Proposed CIMOSA Process Ontology

This section outlines and describes the CIMOSA process ontology written in first-order logic.

5.4.1 Lexicon

In [40], the standards document makes a major distinction between business processes and enterprise activities. Business Processes do not have an ending status; instead, process completion is signalled by the behavioural rule FINISH action and possible exception. In addition, business processes have observable and/or quantifiable results, such as material entities, information entities, new processes, or achievements of one or 3http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_core Chapter 5. The CIMOSA Process Ontology 107 more enterprise objectives [40]. Table 5.2 outlines the general terminology found in the following CIMOSA documentation: [63], [47], [66], [39], and [40]. In the PSL ontology, a lexicon is defined in [22] to indicate the core theories within the ontology (refer to Appendix A.2). Similarly, we define a first-order lexicon for CIMOSA’s various constructs in Table 5.3, with definitions adapted from [47], [66], [39], and [40]. This lexicon includes potential entities, relations, and functions that were considered when developing the process ontology for CIMOSA. To ‘semantically augment’ these CIMOSA constructs with the PSL constructs found in [22], we attempted to do a one-to-one mapping between the terminology in both lexicons. In Table 5.4, we have attempted to compare the lexicons and, where possible, have determined that the following terms are similar, if not potentially equivalent, to each other.

5.4.2 Behavioural Rules for Well-Structured Processes

The following section discusses the possible axiomatizations of the well-structured CIMOSA behavioural rules that were outlined and discussed in Table 5.1 and Section 5.2. The Common Logic versions of the axioms described below can be found in Appendix C.2 and in COLORE4. From Table 5.4, we are able to write the following axioms: A business process in CIMOSA is an activity in PSL. • x ((business process(x) activity(x))). (5.4.1) ∀ ⊃ An enterprise activity in CIMOSA is an activity in PSL. • x ((enterprise activity(x) activity(x))). (5.4.2) ∀ ⊃ An enterprise function in CIMOSA is an activity in PSL. • x ((enterprise function(x) activity(x))). (5.4.3) ∀ ⊃ 4http://code.google.com/p/colore/source/browse/trunk/ontologies/cimosa/ cimosa.clif Chapter 5. The CIMOSA Process Ontology 108

Table 5.2: Definition of Terms Found in CIMOSA, adapted from [63], [47], [66], [39], and [40].

CIMOSA Term Definition Behavioural Rule Description of the sequencing relationships of con- stituent activities used in the specification of Business Process behaviour. Business Processes (BP) Partially ordered set of enterprise activities that can be executed to achieve some desired end-result in pursuit of a given objective of an enterprise or a part of an en- terprise. Domain Part of the enterprise relevant to a set of business ob- jectives and constraints for which a model is created. Ending Status (ES) The termination status of the execution of an occurrence of the activity (such as ‘successful execution’, ‘aborted’, ‘done’ or ‘less than 100 items produced’). Enterprise Activities (EA) All, or part, of process functionality that consists of ele- mentary tasks performed in the enterprise that consume inputs and allocate time and resources to produce out- puts. Enterprise Function (EF) A business process or enterprise activity. Enterprise Model A representation of what an enterprise is composed of, what it intends to accomplish and how it operates in accordance. Enterprise Object Construct that represents a piece of information in the domain of the enterprise that describes a generalized or a real or an abstract entity, which can be conceptualized as being a whole. Event A solicited or unsolicited fact indicating a state change in the enterprise. Occurrence A single, actual realization of an entity in the real world. Chapter 5. The CIMOSA Process Ontology 109

Table 5.3: Lexicon for CIMOSA in first-order logic.

Term Description begin(x) Performs an action (such as carrying out a business process or enterprise activity) when invoked. business process(x) Partially ordered set of enterprise activities that can be executed to achieve the enterprise’s objec- tive. ending status(x) Provides information on the completion or termi- nation of an Enterprise Activity. enterprise activity(x) Elementary tasks performed in the enterprise that consume inputs and allocate time and resources to produce outputs. enterprise function(x) A business process or enterprise activity. enterprise object(x) A generalized or a real or an abstract entity in the enterprise. event(x) A solicited or unsolicited fact indicating a state change in the enterprise or environment. occurrence(x) An occurrence of an enterprise function.

Table 5.4: Comparison between CIMOSA and PSL’s lexicons.

CIMOSA Term PSL Term business process(x) is potentially equivalent to activity(x) enterprise activity(x) is potentially equivalent to activity(x) enterprise function(x) is potentially equivalent to activity(x) event(x) is potentially equivalent to activity(x) occurrence(x) is potentially equivalent to activity occurrence(x) enterprise object(x) is potentially equivalent to object(x) Chapter 5. The CIMOSA Process Ontology 110

An enterprise object in CIMOSA is an object in PSL. • x ((enterprise object(x) object(x))). (5.4.4) ∀ ⊃ An event in CIMOSA is an activity occurrence in PSL. • x ((event(x) activity(x))). (5.4.5) ∀ ⊃ An occurrence in CIMOSA is an activity occurrence in PSL. • x ((occurrence(x) activity occurrence(x))). (5.4.6) ∀ ⊃ All enterprise functions are business processes or enterprise activities • x ((enterprise function(x) ∀ ⊃ business process(x) enterprise activity(x))). (5.4.7) ∨

We can define the Ending Status (ES) values as a constant named ‘end stat 1’.

o x ((occurrence of(o, enterprise function(x)) holds(“end stat 100, o))). (5.4.8) ∀ ∀ ⊃

These ending statuses are values that are specified by the ontology user, depending on the context and the domain(s) of use.

Process Triggering Rules

Recall that the rule indicates that a domain process can be started by one or more events.

WHEN (ST ART W IT H event i AND event j) DOEF 1 − −

Thusly, we can write the following rule using the PSL constructs of occurrence of(o, a) and precedes(o1, o2):

o1 o2 x f ((occurrence of(o1, domain process(x)) ∀ ∀ ∀ ∀ ∧ Chapter 5. The CIMOSA Process Ontology 111

root(o2, o1) occurrence of(o2, enterprise function(f)) ∧ ⊃

o3 o4 i j (precedes(o3, o2) precedes(o4, o2) ∃ ∃ ∃ ∃ ∧ ∧

occurrence of(o3, activity(i)) occurrence of(o4, activity(j))))). (5.4.9) ∧

For rules where a business process is started from a parent process, recall that the original rule is stated as: WHEN (ST ART ) DOEF 1

We can use the PSL construct for root notes in an occurrence tree to write the following:

o1 x ((occurrence of(o1, business process(x)) ∀ ∀ ⊃

o y(root(o, o1) occurrence of(o, business process(y)) precedes(o, o1)))). (5.4.10) ∃ ∃ ∧ ∧

Forced Sequential Rules

With forced sequential rules, a process step must follow another step regardless of the ending status of the previous step. The reserved word ANY is used by the author of [63] to illustrate the disregard for the ending status. They are of the form:

WHEN (ES(EF x) = ANY ) DO EF y

We can write this as follows:

o1 x ((holds(ANY, o1) occurrence of(o1, enterprise function(x)) ∀ ∀ ∧ ⊃

o2 y(occurrence of(o2, enterprise function(y)) precedes(o1, o2)))). (5.4.11) ∃ ∃ ∧ Chapter 5. The CIMOSA Process Ontology 112

Conditional Sequential Rules

Recall that the original rule is stated as:

WHEN (ES(EF 1) = end stat 1) DOEF 2

WHEN (ES(EF 1) = end stat 2) DOEF 3

WHEN (ES(EF 1) = end stat 3) DOEF 4

If the enterprise function x has an ending status value of end stat 1, and o1 is an occur-

rence of x, then there exists an o2 which is an occurrence of enterprise function y that

occurs after o1. We assume end stat 1, end stat 2, etc. are specific ending status values. Thus, we are able to write the above three rules as follows:

00 o1 x ((holds(“end stat 1 , o1) occurrence of(o1, enterprise function(x)) ∀ ∀ ∧ ⊃

o2 y(occurrence of(o2, enterprise function(y)) precedes(o1, o2)))). (5.4.12) ∃ ∃ ∧

00 o2 x ((holds(“end stat 2 , o2) occurrence of(o2, enterprise function(x)) ∀ ∀ ∧ ⊃

o3 y(occurrence of(o3, enterprise function(y)) precedes(o2, o3)))). (5.4.13) ∃ ∃ ∧

00 o3 x ((holds(“end stat 3 , o3) occurrence of(o3, enterprise function(x)) ∀ ∀ ∧ ⊃

o4 y(occurrence of(o4, enterprise function(y)) precedes(o3, o4)))). (5.4.14) ∃ ∃ ∧

Spawning Rules

Recall that spawning rules come in two different forms: asynchronous and synchronous. The asynchronous form is defined in such a way that EF 2, EF 3 and EF 4 will all be Chapter 5. The CIMOSA Process Ontology 113 requested to start as soon as they are enabled after EF 1 finishes with a status value:

WHEN (ES(EF 1) = value) DOEF 2 & EF 3 & EF 4

We can write this in first-order logic, where value is the specific ending status required for spawning to occur, as shown below. We do not know in which order EF 2, EF 3 and EF 4 occurs, so the axiom can be defined as follows:

00 o1 x ((holds(“value , o1) occurrence of(o1, enterprise function(x)) ∀ ∀ ∧ ⊃

o2 o3 o4 t y z (occurrence of(o2, enterprise function(t)) ∃ ∃ ∃ ∃ ∃ ∃ ∧

occurrence of(o3, enterprise function(y)) ∧

occurrence of(o4, enterprise function(z)) precedes(o1, o2) ∧ ∧

precedes(o1, o3) precedes(o1, o4)))). (5.4.15) ∧

The precedence constraint that EF 1 occurs before EF 2, EF 3 and EF 4 is preserved through the use of the precedes(o1, o2), precedes(o1, o3), and precedes(o1, o4) relations, respectively. Similarly, for synchronous spawning, EF 2, EF 3 and EF 4 will all be re- quested to start exactly at the same time assuming that they are all enabled (SYNC indicates the synchronization):

WHEN (ES(EF 1) = value) DOSYNC (EF 2 & EF 3 & EF 4)

To write this in first-order logic, we can assume that EF 2, EF 3 and EF 4 start at the same time point. Thus, we use the beginof(o) function in PSL to indicate that the Chapter 5. The CIMOSA Process Ontology 114 starting time points of EF 2, EF 3 and EF 4 are the same:

00 o1 x ((holds(“value , o1) occurrence of(o1, enterprise function(x)) ∀ ∀ ∧ ⊃

o2 o3 o4 t y z (occurrence of(o2, enterprise function(t)) ∃ ∃ ∃ ∃ ∃ ∃ ∧

occurrence of(o3, enterprise function(y)) ∧

occurrence of(o4, enterprise function(z)) ∧

precedes(o1, o2) precedes(o1, o3) precedes(o1, o4) ∧ ∧ ∧

(beginof(o2) = beginof(o3)) (beginof(o2) = beginof(o4))))). (5.4.16) ∧

Rendezvous Rules

Recall these rules synchronize the end of spawning rules; in this case, EF 5 starts only when EF 2 finishes with a status of value 2, EF 3 finishes with a status of value 3, and EF 4 finishes with a status of value 4.

WHEN (ES(EF 2) = value 2 AND ES(EF 3) = value 3

AND ES(EF 4) = value 4) DOEF 5

Since the ending time points for the enterprise functions EF 2, EF 3 and EF 4 are un- known, and that these functions may not end at the same time, we do not use the endof(o1) function in PSL in the axiomatization of this behavioural rule. If we treat value 2, value 3, and value 4 as constants, then we can write the following rule where the precedence constraint is conserved:

00 o2 o3 o4 x y z ((holds(“value 2 , o2) ∀ ∀ ∀ ∀ ∀ ∀ ∧ Chapter 5. The CIMOSA Process Ontology 115

00 00 holds(“value 3 , o3) holds(“value 4 , o4) ∧ ∧

occurrence of(o2, enterprise function(x)) ∧

occurrence of(o3, enterprise function(y)) ∧

occurrence of(o4, enterprise function(z)) ⊃

o5 t (occurrence of(o5, enterprise function(t)) ∃ ∃ ∧

precedes(o2, o5) precedes(o3, o5) precedes(o4, o5)))). (5.4.17) ∧ ∧

Loop Rules

Loop rules repeat a process step (or several) as long as a given condition holds, or for a defined number of iterations. In the example below, EF1 repeats until it continues to have a status of loop value.

WHEN (ES(EF 1) = loop value) DOEF 1

We can axiomatize this trivially in first-order as:

00 o1 x ((holds(“loop value , o1) ∀ ∀ ∧

occurrence of(o1, enterprise function(x)) ⊃

occurrence of(o1, enterprise function(x)))). (5.4.18)

It is uncertain whether this is the correct axiomatization of this behavioural rule because occurrence of(o1, enterprise function(x)) only occurs once based on the implication. Another potential way of axiomatizing this would be to take a look at the subactivity Chapter 5. The CIMOSA Process Ontology 116

5 6 occurrence ordering theory, Tsoo , in PSL and attempt to use the soo(s, a) relation in a revision to this axiomatization.

Process Completion Rules

Process completion rules indicate the end of an execution of a set of rules. If FINISH can be reached from all STARTs and all process steps used in the rules belong to at least one path from START to FINISH, then the rule is considered consistent, according to [63].

WHEN (ES(EF 1) = end stat x AND ES(EF 2) = end stat y) DOFINISH

This can be written in first-order as follows:

s a o1 o2 b f ((leaf occ(o2, o1) ∀ ∀ ∀ ∀ ∀ ∀ ∧

occurrence of(o2, enterprise function(f) ∧

occurrence of(o1, business process(f)) ⊃

o3 o4 g i j (precedes(o3, o2) precedes(o4, o2) ∃ ∃ ∃ ∃ ∃ ∧ ∧

occurrence of(o3, enterprise function(f)) ∧

occurrence of(o4, enterprise function(g)) ∧

00 00 holds(“end stat x , o3) holds(“end stat x , o4)))). (5.4.19) ∧ 5http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_soo/ soo.clif 6The lexicon for this subactivity occurrence ordering theory can be accessed via: http://www.mel.nist.gov/psl/psl-ontology/part13/soo.th.html. Chapter 5. The CIMOSA Process Ontology 117

5.4.3 Behavioural Rules for Semi-Structured Processes

The following section discusses the possible axiomatizations of the semi-structured CIMOSA behavioural rules that were outlined and discussed in Table 5.1 and Section 5.2. The Common Logic versions of the axioms described below can be found in Appendix C.2 and in COLORE7.

Run-Time Choice Rules

Recall that these rules are used when there is an exclusive choice among several alterna- tives. Exactly one process step will be executed as decided by the resource at run-time:

WHEN (ES(EF 1) = end stat 1) DOS = (EF 2 XOREF 3 XOREF 4)

In first-order logic, the exclusive or (XOR) operator is represented as “one or the other, but not both”: p q (p q) (p q) ⊕ ≡ ∨ ∧ ¬ ∧

Thus, we adopt this format to axiomatize this rule, but assume there is an alternative between two different enterprise functions. If there are three listed, the axiom would be very complex.

00 o1 x ((holds(“end stat 1 , o1) occurrence of(o1, enterprise function(x)) ∀ ∀ ∧ ⊃

o2 o3 y (occurrence of(o2, enterprise function(y)) precedes(o1, o2) ∃ ∃ ∃ ∧ ∧

(occurrence of(o3, enterprise function(y)) precedes(o1, o3)) ¬ ∧ ∨

occurrence of(o3, enterprise function(y)) precedes(o1, o3) ∧ ∧ 7http://code.google.com/p/colore/source/browse/trunk/ontologies/cimosa/ cimosa.clif Chapter 5. The CIMOSA Process Ontology 118

(occurrence of(o2, enterprise function(y)) precedes(o1, o2))))). (5.4.20) ¬ ∧

Unordered Set Rules

They are used to indicate that a set of process steps must be executed, but the order of execution is unknown.

WHEN (ES(EF 1) = end stat 1) DOS = EF 2,EF 3,EF 4 { }

Since the unordered set rule in the CIMOSA documentation does not indicate whether all of these process steps need to be executed, compared to some of the process steps, we make the assumption that the AND operator is used. This means that every process step in the set S must be executed at least once. We represent this in first-order logic as follows:

00 o1 x ((holds(“value , o1) occurrence of(o1, enterprise function(x)) ∀ ∀ ∧ ⊃

o2 o3 o4 t y z (occurrence of(o2, enterprise function(t)) ∃ ∃ ∃ ∃ ∃ ∃ ∧

occurrence of(o3, enterprise function(y)) ∧

occurrence of(o4, enterprise function(z)) ∧

precedes(o1, o2) precedes(o1, o3) precedes(o1, o4)))). (5.4.21) ∧ ∧

5.5 Discussion

The following section discusses the limitations of the applied methodologies in providing CIMOSA with semantics, and the general limitations with the developed ontology. Chapter 5. The CIMOSA Process Ontology 119

5.5.1 Limitations of the Ontology

The proposed CIMOSA ontology only covers the process specifications found in enterprise modelling. In the appendices of [40], there are metamodels that have not been formal- ized within this ontology. These metamodels describe how various CIMOSA concepts and constructs are related to each other via the different views (function, information, resource, and organization). As well, the proposed ontology does not axiomatize any of the different views and flows found in CIMOSA since they are not referred to, nor specified, in the behavioural rule set. Furthermore, the axiomatizations for loop rules, run-time choice rules, and unordered set rules need to be revised to accurately reflect the semantics behind the CIMOSA constructs. With the loop rules, it was indicated that the rule was trivialized to only have the activity occurrence repeat once after a desired ending status is attained. The run-time and unordered set rules will need to be re-examined since their axiomatizations depends on the number of enterprise functions contained within the set S. Consequently, as the number of elements in set S increases, the axiomatizations will be different for every size n of the set S. As well, for the unordered set rules, the documentation indicates that the enterprise functions in set S need to be enacted at least once, but the current axiomatization does not take into account the repetition of enterprise functions within the set. We are currently unsure of how to represent the dynamic characteristics of these behavioural rules.

5.5.2 Inability to Test and Verify Axioms for its Intended Se-

mantics

One of the critical questions with designing ontologies, or attributing ontologies, to al- ready existing standards and frameworks is whether or not the axioms developed are indeed correct. One of the approaches discussed by Gr¨uningerin [21] is to utilize a Chapter 5. The CIMOSA Process Ontology 120 pre-existing software environment to hypothesize that the axiomatizations behave in ac- cordance and make the same predictions as the software. However, since the CIMOSA software was developed in isolation in the late 1990s, we are unable to test our various axiomatizations for correctness since it utilizes its own descriptive language known as the ‘CIMOSA Implementation Descriptive Language’8.

5.5.3 The Need for Ontology Design Best Practices

Currently, there do not exist any generalized ‘best practices’ when it comes to designing new ontologies. There have been discussions about the ontology lifecycle for theorem proving [43] and within biomedical informatics [54], but there do not exist any general best practices to create ontologies from standardized formalisms and frameworks such as the Integration DEFinition (IDEF) family of constructs and CIMOSA, respectively. With respect to the methodology for ontology verification described in [43], ontologies can be verified if the intended models of the ontology are known. In the circumstance with CIMOSA, we are not sure what the specification of the ontology’s intended models are supposed to look like in the Requirements Phase, nor do we know how to axiomatize the models that are captured by the requirements in the Design Phase of the ontology design lifecycle. Since the initial two phases of this methodology cannot be carried out with respect to CIMOSA, we have identified that there is a need for a general methodology, or suggested best practices, for designing ontologies from established standards.

5.6 Challenges & Difficulties Encountered

The following challenges and difficulties were encountered in this case study.

8This implementation language is described in detail in [1]. Chapter 5. The CIMOSA Process Ontology 121

Lack of Ontology Design Methodologies

To our knowledge, there have not been methodologies proposed for the ontology design process. While there are approaches to develop ontologies through natural-language processing (NLP) techniques, such as those found in [56], NLP search capabilities are often assumed to be limitless and provide unrealistic expectations of results for end-users. As well, they are costly to implement and may perform worse than simple, keyword-based search engines once their limits have been reached. Given these limitations, however, there is an implicit understanding within the ontology community that there exists a life cycle in which ontologies are created, evaluated, and fixed, similar to workflows and design patterns found in project management and software development. Since this case study required the creation of new axioms to describe CIMOSA’s behavioural rules, the adopted ‘methodology’ developed the proposed axioms has been ad-hoc. While we initially started off with competency questions and an collection of commonly-used terminology found in the behavioural rule set, we realized that the chal- lenge lies in how the reader interprets the context and content of the CIMOSA documen- tation.

Technical Jargon and Ambiguous Phrasing Hinder Understand- ing of Semantics

With the two standards documents, there is a lot of legal writing, or ‘legalese,’ used. Despite the fact that these standards are not government standards and are not legally binding, the intent of the documents is to ensure that the CIMOSA framework is used in a consistent manner. Regardless of this fact, the wording in certain parts of the standards documents is ambiguous and prevents the reader from fully understanding the intent of the writing. For example, in the ‘Compliance Principles’ section of [40], the following is specified: A model can also claim compliance to this standard if it is (i) a valid construc- Chapter 5. The CIMOSA Process Ontology 122

tion of a modelling language that is itself compliant, or (ii) for a modelling language claiming qualified compliance, if the model uses only those modelling language constructs that are mappable to the constructs of this standard.

Nowhere in [40] is a model specified for CIMOSA, or any of the other formalisms found within this standards document. The term ‘model’ is defined ambiguously, in both [39] and [40], as: [an] abstract description of reality in any form (including mathematical, phys- ical, symbolic, graphical, or descriptive) that presents a certain aspect of that reality.

The ambiguous phrasing used in this definition makes it difficult for the reader to fully understand what a CIMOSA - or more generally, an enterprise - model should encompass.

Uncertainty of the Role of CIMOSA Dimensions in Process Spec- ification of the Behavioural Rule Set

Part of the challenge with axiomatizing CIMOSA is that we are unsure of the role of the dimensions of genericity, views, and life cycle outlined in Section 5.2 have in the behavioural rule set. We were also unsure of how these constructs could be axiomatized in first-order logic. Similarly, we were uncertain as to how the different flows (control, material, information) could be represented in the proposed ontology.

Describing CIMOSA’s Looping Rules with PSL Constructs

With respect to looping rules found in CIMOSA, the construct is similar to that of the graphical formalism found in the Integrated DEFinition for Process Description Capture Method (IDEF3) and the Unified Modelling Language (UML). IDEF3 allows cyclic order- ings in its formalisms, so additional work will need to be done to determine how to repre- sent these orderings axiomatically for CIMOSA; the soo(s, a) and soo precedes(s1, s2, a) relations from PSL, or other relations in other theories, may need to be created in order to axiomatize the looping rules. Chapter 5. The CIMOSA Process Ontology 123

5.7 Insights

From this case study, we have gathered additional insight on the ontology design process, along with the difficulties of developing semantics for an area that lacks formalisms to properly describe commonly-used constructs within enterprise modelling. This case study has outlined potential research areas that may be of interest within the ontology, international standards, and enterprise engineering communities, as well as a starting point for ‘ontologizing’ standards and frameworks found within the ISO. Chapter 6

Ontology Mapping: ServicedAtHome

In contrast to the previous chapters, here we describe a case study where rich sets of axioms were not provided nor used to map two ontologies together. This case study examines how two weak ontologies, with no semantics, can be mapped together in the e-commerce setting. ServicedAtHome is a website designed to integrate home product and service data intended to assist home owners, the users, to take better care of their homes. It integrates this data from various heterogeneous providers, but the semantic heterogeneity problem arises when different meanings of terms are used to describe the same products. The current challenge for ServicedAtHome is to integrate the data by the primary providers, Amazon and Sears, through the means of a semi-autonomous exchange of information; this means that there should be an automated mapping of data to reduce the amount of manual processing required. In order to do this, computer-interpretable ontologies are needed to provide a set of terms and the assigned meanings of these terms in a formal logical language. The development of ontologies assists with the semantic integration of software systems since ontologies contain a shared understanding of the terminology found within each provider.

124 Chapter 6. Serviced At Home 125

6.1 Background & Motivation

In this section, we outline our primary motivations for undertaking this case study with Hunch Manifest, Inc., and describe the data and infrastructure involved.

6.1.1 Hunch Manifest, Inc.

Internationally, the home improvement industry is approximately a $500 billion USD industry: material and merchandise retail sales comprise approximately one third and home service providers two thirds [16]. Hunch Manifest, Inc.1 is a privately owned company founded in 2011 with the goal of creating innovative, sustainable and practical resources for people, their residences, and their community. The company’s first product, www.ServicedAtHome.com, is Canada’s only home service marketplace that retrieves quotes from providers that are trusted by friends and family. Today, the company is poised to redefine the home improvement industry using an intelligent suite of semantic web tools and design methods. This case study was carried out as an industry-research partnership project with Hunch Manifest, Inc. in the form of a Natural Sciences and Engineering Research Council of Canada (NSERC) Engage grant2. The results of this project will help the industry take a step forward through the introduction of semantic technology into an online e-commerce application. By adding intelligence and extending semantic capability to its back-end infrastructure, Service- dAtHome brings much needed utility to consumers by improving the system’s ability to organize resources given the definition of some home improvement work. The user on the front-end will utilize a tool that will intelligently aid them in planning as well as intelligently recommend resources to execute the work plan. 1http://www.hunchmanifest.com/ 2These grants are designed to give companies access to the knowledge and expertise available at Canadian universities, and are intended to foster the development of new research partnerships by supporting short-term research and development projects aimed at addressing a company-specific prob- lem. Additional information about the NSERC Engage Partnership can be found via http://www. nserc-crsng.gc.ca/Professors-Professeurs/RPP-PP/Engage-engagement_eng.asp. Chapter 6. Serviced At Home 126

The purpose of this project was to utilize semantic data integration techniques to semantically map the service providers’ data together, along with providing any necessary mappings between ServicedAtHome’s HomeServices Ontology and other ontologies from third-party product and service providers. This case study attempts to address the problems of generating and verifying such ontology mappings.

ServicedAtHome

ServicedAtHome.com is an online service which matches home owners with resources to help them carry out tasks within their home. Resources may include service providers (e.g., plumbers, contractors), material (e.g., bathroom fixtures), and tools (e.g., wrenches, power drills). When a home owner defines the work they intend to complete in their home, ServicedAtHome processes the request, consolidates information and makes recommen- dations of available resources.

The HomeServices Ontology (HSO)

In order to process requests, ServicedAtHome has developed the HomeServices Ontol- ogy (HSO) deconstruct the requests into terminology the system can understand. The ontology is currently written in OWL and organizes knowledge pertaining to the home domain; it is based on the gist ontology, a minimalist upper ontology 3 that describes typ- ical business concepts. Since the Home Services Ontology (HSO) was already developed in OWL and Hunch Manifest, Inc. preferred using the OWL syntax, first-order logic and Common Logic were not used in this case study.

6.1.2 Semantic Integration of Product and Service Data

ServicedAtHome.com integrates home product and service data from numerous hetero- geneous providers, who distribute their information to publishers in order to sell on their

3An upper ontology describes generic concepts that are the same across all knowledge domains and are designed with the intention to support broad semantic interoperability between other ontologies. Chapter 6. Serviced At Home 127 behalf in exchange for a commission. A key consolidation challenge with disparate data sources, however, is semantic heterogeneity. For example, a hammer is a type of tool but may also refer to the hip-hop artist “MC Hammer”, a West Sussex location, or a comic book character. This clash over the meaning of the terms prevents the seamless exchange of information among the providers. Therefore, a challenge for the business is to integrate data in a manner that increases mapping automation and reduces manual processing (such as semi-autonomous data integration). The development of ontologies has been proposed as a key technology to support semantic integration [30]. Ontologies are logical theories that provide a set of terms together with a computer-interpretable specification of the meanings of the terms in some formal logical language. The seman- tic integration of software systems is supported through a shared understanding of the terminology in their respective ontologies.

6.2 Infrastructure of Mapping Services & Ontologies

For the purposes of this case study, Hunch Manifest, Inc. was interested in integrating home improvement product information provided by Amazon and Sears. Access to the Amazon and Sears Application Programming Interfaces (APIs) was provided by the com- pany to retrieve the necessary product information in the Extensible Markup Language (XML) format. From the raw product data, we were able to develop API response ontolo- gies in OWL for each company based on how the XML tags were structured. However, part of the project requirements was to test the mappings between the HSO and the API ontologies using Franz, Inc.’s AllegroGraph Data Store, which is a graph database that has reasoning and ontology modelling capabilities. In order to do this, the conversion of XML product data into the Resource Description Framework (RDF) format was re- quired. The mappings are then expressed in RDF syntax to be used by AllegroGraph to return the desired results to the user. Chapter 6. Serviced At Home 128

Figure 6.1 summarizes the relationships between the different API technologies and ontologies involved in this case study. The intent of the front-end ServicedAtHome web application is to receive queries from the users of the system (usually homeowners who wish to carry out some home renovation project) and to provide users with a response to their queries. Queries to the system were intended to be comparative in nature, such as asking for the cheapest product offered by both vendors or for the average price of a given product. At the back-end of the system, there are scripts which run queries against the corresponding vendor APIs and retrieves those results in XML form. Since this case study was intended to be a proof of concept for Hunch Manifest, Inc., we were instructed to develop ontologies derived from the XML API responses in the OWL syntax. However, as the case study progressed, these OWL ontologies were not utilized to their fullest nature to test the ontology mappings since Hunch Manifest, Inc. had preferred to utilize the AllegroGraph Data Store to store all of the product information and to reason with the mappings. As outlined in future subsections, what resulted was that RDF subtheories were extracted from the developed OWL ontologies, and all of the product data needed to be imported into the data store in the RDF format in order to test the vendor mappings using SPARQL Protocol and RDF Query Language (SPARQL) queries. From there, the mapped results of the queries are outputted by AllegroGraph back to the user.

6.3 Methodology

In order to map the vendor product data together, an ad-hoc approach was taken in order to understand the framework’s implicit semantics. The subsequent sections that follow outline the steps taken to develop the mappings between the two vendors, which include:

Acquiring sample product data through the vendors’ APIs. • Chapter 6. Serviced At Home 129

ServicedAtHome Mapping Front-End Query from User Response to User

ServicedAtHome Mapping Back-End

API Queries

Amazon.com Amazon.com API Response OWL Ontology

Amazon.com API XML Response Allegrograph RDF Data Store

Amazon.com API Response RDF Ontology Mapped Results

Sears.com Response RDF Ontology Sears.com

Sears.com API XML Response Sears.com API Response OWL Ontology

Figure 6.1: Relationship between the different API technologies and ontologies. Chapter 6. Serviced At Home 130

Developing the vendor API ontologies through the examination of sample product • data. Identifying the product concepts to be mapped from the ontologies. • Transforming the raw product data into a computer-interpretable format for se- • mantic integration. Mapping the product data by querying a semantic data store. • In summary, the ‘methodology’ taken was ad-hoc in nature since we were uncertain of whether the product vendors leveraged any semantic technologies in their product infor- mation. Upon realizing that we would need to do an initial data collection to understand the underlying concepts found in the product information, we decided that the initial data sample would suffice to develop proof-of-concept mappings with the HSO ontology. Once the concepts were identified, we then had to determine which concepts were similar in meaning and could be mapped together to provide us with the expected results. After the initial set of mappings was determined, the raw product data needed to be converted into a usable format for the data store before testing out the mappings in the SPARQL.

6.3.1 Acquiring Sample Vendor Product Details

Before we could develop the vendor ontologies, we needed to determine what kind of concepts are described in the raw product data. For the purposes of this project, we arbitrarily selected five different products that are offered by both Amazon and Sears: 1. Black & Decker LDX112C 12-Volt MAX Lithium-Ion Drill/Driver 2. Tajima Tool Corp - Rapid Pull 265 15 TPI blade 3. Craftsman 16 oz. Rubber Mallet 4. Delta Faucet U4993-SS Universal Showering Components Shower Arm and Flange, Stainless

5. KNIPEX 95 12 200 Comfort Grip Cable Shears

In order to run queries to retrieve the five products’ information against the product vendors’ APIs, we utilized the following tools: Chapter 6. Serviced At Home 131

1. Amazon’s Product Advertising API ScratchPad This tool is provided by Amazon for developers to easily query the Amazon API. We primarily used this tool to retrieve the Amazon product information in the form of a single line query. Refer to Appendix D.3 for the queries use to retrieve the Amazon product information.

2. Git for Windows (to utilize the cURL tool) Since Sears only allows its API to be queried through cURL commands, we were required to install this version of Git on Windows to query the Sears API. (Alter- natively, the cURL software is preinstalled on Linux environments.)

6.3.2 Developing the Vendor API Ontologies

To create the ontologies required to map the product tags used by both vendors, we created Web Ontology Language (OWL) versions of the metadata tags used in the XML result sets. The OWL ontologies were created using the Prot´eg´eOntology Editor4.

The Amazon API Result Set Ontology

For this ontology, we took the results that are generated from the API queries and extract the tags that we require for the mapping process. In this case, since the ItemSearch and ItemLookUp operations return similar metadata tags (refer to Appendix D.1), we were able to develop a rudimentary ontology from the XML output. The ItemLookup opera- tions returns some or all of the attributes for one product, whereas the ItemSearch op- eration returns products that satisfy a given search criteria. The major difference between the two operations is that many search parameters can be specified in ItemSearch and it is possible to search products by keyword through ItemSearch. Example attributes returned by both operations include the ASIN number, ItemAttributes, Title, ProductGroup, Price, and Manufacturer of the product. Amazon categorizes its offerings in the form of spreadsheets through the Amazon Seller Central website5. For the purposes of this case study, we only included the cate-

4For this case study, Prot´eg´eversion 4.2.0 was used and can be found at http://protege. stanford.edu/. 5https://sellercentral.amazon.com/gp/homepage.html Chapter 6. Serviced At Home 132 gorization of the Tools & Home Improvement section of the spreadsheets. For each class of items, we drill down on the various types of items that Amazon has to offer in these categories and add them as subclasses in the API ontology. For example, if we look at the Drills category on Amazon, we find the following: Tools • – Drills Core Drills ∗ Hammer Drills ∗ Pistol-Grip Drills ∗

From the API results, we created datatype properties for all of the metadata tags that encapsulate a product’s information. Some of these tags are outlined in Table 6.1. Object properties in the ontology were not created because of how the product metadata is structured. There were no indications within the returned XML responses whether a product class has object properties; all of the XML responses encapsulated information in strings/literals, integers, and/or doubles.

The Sears API Result Set Ontology

For this ontology, we took the results that were generated from the API queries and ex- tract the tags that we require for the mapping process. In this case, since the ProductSearch and ProductDetails APIs return similar metadata tags (refer to Appendix D.2), we are able to develop a rudimentary ontology from the XML output. The ProductSearch API allows developers to search and browse the Sears.com, KMart.com, and mygofer.com catalogues for products; similarly, the ProductDetails API allows developers to re- trieve product details from the aforementioned vendors. Example attributes returned by both APIs include the Sears PartNumber, MfgPartNumber (if applicable), BrandName, Price, and DescriptionName of the product. Unlike Amazon, Sears does not have any formal documents specifying their catego- rization of products and offerings. However, all of the Sears verticals (and subcategories) Chapter 6. Serviced At Home 133

Table 6.1: Excerpt of metadata tags found in the Amazon XML result set, along with the names used in OWL relations.

Amazon XML Tag OWL Relation Name Functional? ASIN ASIN Yes DetailPageURL DetailPageURL Yes ItemLink ItemLink Yes Description Description Yes URL URL Yes ItemAttributes ItemAttributes Yes Binding Binding Yes Brand Brand Yes CatalogNumberList CatalogNumberList Yes CatalogNumberListElement CatalogNumberListElement Yes EAN EAN Yes EANList EANList Yes EANListElement EANListElement Yes Feature Feature Yes ItemDimensions ItemDimensions Yes Height Height Yes Length Length Yes Weight Weight Yes Width Width Yes Label Label Yes ListPrice ListPrice Yes Amount Amount Yes CurrencyCode CurrencyCode Yes FormattedPrice FormattedPrice Yes Manufacturer Manufacturer Yes Model Model Yes MPN MPN Yes PackageDimensions PackageDimensions Yes PackageQuantity PackageQuantity Yes PartNumber PartNumber Yes ProductGroup ProductGroup Yes ProductTypeName ProductTypeName Yes Publisher Publisher Yes SKU SKU Yes Studio Studio Yes Title Title Yes UPC UPC Yes UPCList UPCList Yes UPCListElement UPCListElement Yes Warranty Warranty Yes Chapter 6. Serviced At Home 134 are listed on a page on the Sears website6. For the purposes of this case study, we only included the categorization of the Tools section in the API ontology. For example, if we look at the Air Compressors & Air Tools category on Sears, we find the following:

Tools • – Air Compressors & Air Tools Air Compressor Accessories ∗ Air Compressors ∗ Air Hoses ∗ Air Tool Accessories ∗ ...etc. ∗

From the API results, we created datatype properties for all of the metadata tags that encapsulated a product’s information. Some of these tags are outlined in Table 6.2. Similar to Amazon, object properties were not created in the ontology because of how the product metadata is structured. There were no indications within the returned XML responses whether a product class has object properties; all of the XML responses encapsulated information in strings/literals, integers, and/or doubles.

Table 6.2: Excerpt of metadata tags found in the Sears XML result set, along with the names used in OWL relations.

Sears XML Tag OWL Relation Name Functional? PartNumber PartNumber Yes Name Name Yes CutPrice CutPrice Yes SkuPartNumber SkuPartNumber Yes BrandName BrandName Yes CutPrice CutPrice Yes DisplayPrice DisplayPrice Yes CatEntryId CatEntryId Yes MfgPartNumber MfgPartNumber Yes KsnValue KsnValue Yes

6http://www.sears.com/shc/s/smv_10153_12605 Chapter 6. Serviced At Home 135

6.3.3 Identifying the Concepts to be Mapped

Prior to mapping the ontologies together, product concepts that could be potentially mapped together needed to be identified. The following steps were carried out to gain a better understanding of the relations utilized in the ontologies involved:

1. Examination of the XML tags used by Amazon and Sears to determine whether there was any product information that was the same. Where there were similari- ties, the XML tags were listed side-by-side in a table.

2. Examination of any similar tags found in the GoodRelations and gist ontologies with the product data to determine any similarities across all of the ontologies.

6.3.4 Preliminary Mappings Between Amazon and Sears

Due to the uncertainty of which concepts could be mapped together, the raw XML data were examined and the vendor ontologies were developed to gain a better understanding of the possible concepts that could be mapped. In Table 6.3, we list the direct 1:1 mappings between Amazon and Sears (empty cells indicate that there was no mapping possible).

Mapping Brand, Publisher, Manufacturer Tags

Due to the limited number of metadata tags used by Sears, we could only map a small subset of their tags with Amazon. For example, Amazon has XML tags to describe the Publisher, Brand, and Manufacturer, whereas Sears only has the BrandName tag to describe the producer of the product. While there are circumstances where the manufacturer of a product is not the same as the brand, we decided to map these concepts together to ensure greater overlap between the different product information.

Amazon : P ublisher Sears : BrandName (6.3.1) ≡

Amazon : Brand Sears : BrandName (6.3.2) ≡ Chapter 6. Serviced At Home 136

Amazon : Manufacturer Sears : BrandName (6.3.3) ≡

Mapping Identifiers (Model, PartNumber, MPN, EAN, SKU)

Amazon uses several identifiers to describe a product: the Model (Model), the Model Product Number (MPN), the Part Number (PartNumber), the Stock Keeping Unit (SKU), the International Article Number (EAN), and for books, the International Stan- dard Book Number (ISBN). Since this case study only examined products required for home improvement, ISBN numbers were not considered in our mappings. In contrast, Sears only utilizes two metadata tags that describe product identifiers: MfgPartNumber and SKU. Looking over the sample product data, we noticed that the SKU tags in Sears are empty 7. While the SKU concepts can be mapped together, the mapping is of little or no use since the following mapping cannot be verified with the product data:

Amazon : SKU Sears : BrandName (6.3.4) ≡

Sears does not have any tags to describe the EAN number. Thus, only the MfgPartNumber in Sears could be mapped with Amazon’s product identifiers. An interesting point to note is that the contents of Sear’s MfgPartNumber are inconsistent; sometimes the model number is listed instead of the manufacturer’s part number8. Thus, we have also mapped MfgPartNumber to Amazon’s Model.

Amazon : Model Sears : MfgP artNumber (6.3.5) ≡

Amazon : P artNumber Sears : MfgP artNumber (6.3.6) ≡

Amazon : MPN Sears : MfgP artNumber (6.3.7) ≡ 7Refer to Appendix D.2; the Sku and SkuList tags are empty. 8For example, KNIPEX 95 12 200 Comfort Grip Cable Shears listed in Amazon have a Model of ‘95 12 200’ and a MPN value of ‘95128’, but in Sears, the MfgPartNumber is listed as ‘95 12 200,’ which is inconsistent with Amazon. Chapter 6. Serviced At Home 137

Mapping Features, Product Titles, and Descriptions

Another way to determine whether both vendors offer the same product is to compare their product titles. In Amazon, the Title tag contains the product title, whereas in Sears, the product titles are inconsistently described in the Title and DescriptionName identifiers. Amazon : T itle Sears : T itle (6.3.8) ≡

Amazon : T itle Sears : DescriptionName (6.3.9) ≡ Furthermore, product features are described as literals in Amazon under the Feature tag, whereas Sears also describes product features in literals in the ShortDescription, and LongDescription tags. Since there was no way of breaking down strings of literals to extract product feature information, only the following mappings could be developed to compare the literals found in these tags: Amazon : F eature Sears : ShortDescription (6.3.10) ≡

Amazon : F eature Sears : LongDescription (6.3.11) ≡

Mapping Product Details and Prices

To map product details, Amazon utilizes the Offer tag that encompasses all of the tags described above. Sears also uses a ProductDetail tag that contains all of the product information tags. These two tags can be mapped together, but not verified since the contents are nested tags that further break down the description of a product (refer to Appendices D.1 and D.2). Amazon : Offer Sears : P roductDetail (6.3.12) ≡ With product prices, Amazon uses the Price tag to describe prices, whereas Sears has two different tags for prices: RegularPrice and SalesPrice. These tags are mapped together as follows: Amazon : P rice Sears : RegularP rice (6.3.13) ≡ Chapter 6. Serviced At Home 138

Amazon : P rice Sears : SaleP rice (6.3.14) ≡

Mapping Product Dimensions and Weight

Amazon has the Height, Length, Width, and Weight to describe a product’s di- mensions and weight. In contrast, Sears does not have any tags to describe product dimensions, so there are no mappings between Amazon and Sears for these product concepts.

Table 6.3: Direct mappings between relations found in the Amazon and Sears OWL ontologies.

Amazon Relation Sears Relation amazon:Publisher / amazon:Brand sears:BrandName amazon:Publisher sears:BrandName amazon:Brand sears:BrandName amazon:SKU sears:Sku amazon:Model sears:MfgPartNumber amazon:PartNumber sears:MfgPartNumber amazon:MPN sears:MfgPartNumber amazon:Title sears:Title amazon:Title sears:DescriptionName amazon:Feature sears:ShortDescription amazon:Feature sears:LongDescription amazon:Manufacturer sears:BrandName amazon:Height amazon:Length amazon:Width amazon:Weight amazon:Offer sears:ProductDetail amazon:EAN amazon:Price sears:RegularPrice / sears:SalePrice

6.3.5 Preliminary Mappings Between HSO and GoodRelations

Since the HSO ontology imports relations found in the gist ontology, it was possible to map the gist relations with those found in GoodRelations. Table 6.4 outlines the Chapter 6. Serviced At Home 139 preliminary mappings between the two ontologies and the subsections that follow describe the rationale behind the mappings.

Mapping Brand, Publisher, Manufacturer Tags

The hasManufacturer relation in GoodRelations can be mapped to the producedBy relation found in gist since both describe the producer of a product.

gr : hasManufacturer gist : producedBy (6.3.15) ≡

Mapping Identifiers (Model, PartNumber, MPN, EAN, SKU)

GoodRelations uses the model part number (hasMPN) and the International Article Number (hasEAN UCC-13) as product identifiers. The hasMPN relation is mapped to gist’s ProductOffering relation, and the hasEAN UCC-13 relation is mapped to both the hasBeenAllocated and ID relations in gist. Since gist does not have any specific relations to describe the various (international) identifiers, the hasBeenAllocated relation can be used to indicate that a product has been allocated an identifier. Similarly, the hasStockKeepingUnit relation in GoodRelations is mapped to the ID relation in gist. gr : hasMP N gist : P roductOffering ≡

gr : hasEAN UCC 13 gist : hasBeenAllocated − ≡

gr : hasEAN UCC 13 gist : ID − ≡

gr : hasStockKeepingUnit gist : ID ≡ Chapter 6. Serviced At Home 140

Mapping Features, Product Titles, and Descriptions

GoodRelations has the name relation to describe the product, so it is also mapped to the name relation in gist to describe the product title.

gr : name gist : name ≡

In GoodRelations, the description relation contains a textual description of the prod- uct, so it is mapped to the Offering relation found in gist. Similarly, the hasFeature relation in gist is mapped with description in GoodRelations.

gr : description gist : Offering ≡

gr : description gist : hasF eature ≡

Mapping Product Details and Prices

GoodRelations uses the hasMakeAndModel relation to indicate that a product instance has a definable make and model, while the ProductOffering relation in gist describes something that can be warehoused. While the concepts are similar in nature (they both describe a product), they are mapped as follows:

gr : hasMakeAndModel gist : P roductOffering ≡

Likewise, the ProductOrService relation in GoodRelations describes all products and classes, which is equivalent to the ProductOffering relation in GIST.

gr : P roductOrService gist : P roductOffering ≡ Chapter 6. Serviced At Home 141

In GoodRelations, the Offering relation specifies a product or service that can be offered with commercial properties [36]. Similarly, in GIST, the Term relation is a description of the specifics of an offer, thus we consider the following equivalence:

gr : Offering gist : T erm ≡

For currency values, the hasCurrencyValue relation in GoodRelations describes the amount of money for a price per unit, shipping charges, or payment charge [36]; and the currencyValue relation in gist is the magnitude of a monetary value.

gr : hasCurrencyV alue gist : currencyV alue ≡

Mapping Product Dimensions and Weight

In GoodRelations, the height, depth, and width relations are used to describe prod- ucts, but since there are no relations in gist that describe product dimensions, we declared these relations as subclasses of the Magnitude9 relation in gist.

gr : height gist : Magnitude v

gr : depth gist : Magnitude v

gr : width gist : Magnitude v

The weight and Weight relations in GoodRelations and gist are also mapped together.

gr : weight gist : W eight ≡

9The Magnitude relation indicates a scalar value which is either measured, estimated or set as a reference value [53]. Chapter 6. Serviced At Home 142

Table 6.4: Direct mappings between relations found in the GoodRelations and HomeSer- vices/GIST OWL ontologies.

GoodRelations HomeServices/GIST Relation gr:hasMakeAndModel gist:ProductOffering gr:StockKeepingUnit gist:ID gr:ProductOrServiceModel gist:ProductOffering gr:hasMPN gist:ProductOffering gr:name gist:name gr:description gist:hasFeature gr:hasManufacturer gist:producedBy gr:description gist:Offering gr:ProductOrService gist:ProductOffering gr:height declare subclassof gist:Magnitude gr:depth declare subclassof gist:Magnitude gr:width declare subclassof gist:Magnitude gr:weight gist:Weight gr:Offering gist:Term gr:hasEAN UCC-13 gist:hasBeenAllocated gr:hasEAN UCC-13 gist:ID gr:hasCurrencyValue gist:currencyValue

6.3.6 Transforming XML Product Data into RDF

The XML product data was initially converted into the Terse RDF Triple Language (Turtle) (*.ttl) syntax with TopBraid Composer, an integrated development environment for building semantic applications provided by Hunch Manifest, Inc., but the converted data was unusable. The converted data contained many blank nodes that were inserted by the tool and the hierarchical structure of the datatype properties was not preserved. To remedy this, custom Extensible Stylesheet Language Transformations (XSLT) stylesheets were written to convert both vendors’ product data into the desired RDF format that preserved the structure found in the raw XML.

Gleaning Resource Descriptions from Dialects of Languages (GRDDL)

The Gleaning Resource Descriptions from Dialects of Languages (GRDDL) is used to obtain RDF data from XML documents and Extensible HyperText Markup Language Chapter 6. Serviced At Home 143

(XHTML) web pages. Transformation algorithms are specified in XSL format in the tag found in the document; GRDDL works by associating transformations using direct references found in the document to be transformed, or indirectly through profile and namespace documents [33]. Appendix D.4.1 briefly outlines the requirements for transforming XML/XHTML documents. Due to time constraints, we did not use GRDDL in this case study but developed custom XSLT stylesheets instead to directly transform the XML data into valid RDF documents. This was due to prior familiarity with developing XSLT stylesheets and the lack of time to learn how to develop transformations and mechanical rules in accordance to the GRDDL specifications of [11]. Furthermore, the XML output generated from the vendor APIs were simple in structure and were not XHTML documents that contained microformat data or embedded semantic markup; it was appropriate to apply a XSLT stylesheet to directly transform the data into the required format. However, we do note that it would be an area of future work to rewrite the XSLT stylesheets in accordance with the GRDDL mechanical rules to ensure greater reusability and to be done in accordance to the World Wide Web Consortium (W3C) standards.

XSLT Stylesheets for Amazon and Sears

Two XSLT stylesheets were created to convert the raw product data from each vendor into a validated RDF file10. The xsltproc tool11 that is included in the XSLT C library for the GNOME desktop environment was used to transform the XML into RDF. Each of the stylesheets matches a template to patterns found in the XML data. For example, in the code snippet below, a template is applied to the entire XML file and assigns the appropriate namespaces in the header of the RDF document. Then, the appropriate

10All of the RDF triples generated in the transformation have been validated using the W3C’s RDF Validation Service: http://www.w3.org/RDF/Validator/. 11The Windows binaries of the xsltproc tool provided by Igor Zlatkovi´cwere used to apply the stylesheets to the raw XML data. Instructions on how to apply the stylesheets to product data can be found in Appendix D.4.2. Chapter 6. Serviced At Home 144

attributes and properties are added; the values found in the XML tags are extracted from the XML document using the xsl:value-of select statement.

Code 6.1: Sample XSLT template to transform an XML document into a RDF document.

The stylesheets are organized and designed according to the original structure found in the XML documents. For example, in the Amazon product data, we have the following format:

Code 6.2: Sample XML from Amazon product data. Tools & Home Improvement Black & Decker 383724 LDX112C 0999900010328 ... Chapter 6. Serviced At Home 145

This format is retained in the RDF version of the product data in the templates; for the above example, the vendor namespace (amazon or sears) is appended to the product- specific tags and the appropriate RDF attributes are added where needed.

Code 6.3: RDF version of XML product data. − − − Tools & Home Improvement Black & Decker 383724 LDX112C 0999900010328 ...

After these stylesheets were applied to the XML product data, the RDF product data was imported12 into the AllegroGraph RDF data store.

6.3.7 Mapping the Vendor Product Data

In order to test the product mappings, the mappings discussed in Sections 6.3.4 and 6.3.5 were converted into RDF syntax and imported into AllegroGraph. As well, RDF subtheories were extracted13 from the vendor OWL ontologies and imported into Allegro- Graph. To test the mappings, SPARQL queries based on the mapped relations specified

12Detailed instructions on how to import the product data into AllegroGraph can be found in Ap- pendix D.5.1. 13The OWL ontologies were converted into RDF syntax. Since there were no semantics in the OWL ontologies, the conversion to RDF syntax did not affect the semantics of the ontologies. Chapter 6. Serviced At Home 146

in Tables 6.3 and 6.4 were written to retrieve and compare product information. These SPARQL queries are discussed in more detail in the next section.

6.4 Product Mappings in RDF and OWL

The mappings outlined in Sections 6.3.4 and 6.3.5 use the owl:equivalentProperty relation in OWL to outline the equivalence between the concepts. We modified the mappings during this part of the project so that the HSO ontology maps into each vendor individually, as shown in Figure 6.2 below.

Amazon HSO e.g., Amazon:Brand e.g., gist:ProducedBy

Sears GoodRelations e.g., Sears:BrandName e.g., gr:hasBrand

Figure 6.2: Relationship between the mappings across the different ontologies.

6.4.1 Mappings Between HSO and Amazon

This section outlines the mappings between the HomeServices Ontology and Amazon ontology in the Turtle format14 using the owl:equivalentProperty relation. In OWL, the owl:equivalentProperty construct is used to state that two properties (relations) are equivalent. Thus, in the mappings below, the triples are listed in the subject-predicate-object format; for example, the gist:ProductOffering relation is equivalent to the amazon:Publisher relation.

14This format is also accepted by AllegroGraph in conjunction with the RDF sytanx and is easier to display in print. Chapter 6. Serviced At Home 147

Mapping 6.4: Mapping between HSO and Amazon. gist :ProductOffering owl:equivalentProperty amazon:Publisher. gist :ProductOffering owl:equivalentProperty amazon:Brand. gist :ProductOffering owl:equivalentProperty amazon:hasModel. gist :ProductOffering owl:equivalentProperty amazon:MPN. gist :name owl:equivalentProperty amazon:Title. gist :hasFeature owl:equivalentProperty amazon:Feature. gist :hasFeature owl:equivalentProperty amazon:Feature. gist :producedBy owl:equivalentProperty amazon:Manufacturer. gist :Term owl:equivalentProperty amazon:Offer. gist :hasBeenAllocated owl:equivalentProperty amazon:EAN. gist :ID owl:equivalentProperty amazon:EAN. gist :currencyValue owl:equivalentProperty amazon:Price.

6.4.2 Mappings Between HSO and Sears

This section outlines the mappings between the HomeServices Ontology and Sears on- tology in Turtle form using the owl:equivalentProperty relation.

Mapping 6.5: Mapping between HSO and Sears. gist :ProductOffering owl:equivalentProperty sears:BrandName. gist :ProductOffering owl:equivalentProperty sears :MfgPartNumber. gist :ProductOffering owl:equivalentProperty sears :MfgPartNumber. gist:name owl:equivalentProperty sears:Title. gist :hasFeature owl:equivalentProperty sears:ShortDescription. gist :hasFeature owl:equivalentProperty sears:LongDescription. gist :producedBy owl:equivalentProperty sears :BrandName. gist :Term owl:equivalentProperty sears:ProductDetail. gist :currencyValue owl:equivalentProperty sears:RegularPrice. gist:currencyValue owl:equivalentProperty sears:SalePrice.

6.4.3 Mappings Between Amazon and Sears

From the two previous sections, the following bidirectional mappings should be inferred by AllegroGraph’s reasoner tool. These mappings have been included to indicate which concepts in both vendor ontologies should be mapped together.

Mapping 6.6: Mapping between Amazon and Sears. Chapter 6. Serviced At Home 148 amazon:Publisher owl:equivalentProperty sears :BrandName. amazon:Brand owl: equivalentProperty sears :BrandName. amazon:SKU owl:equivalentProperty sears :Sku. amazon:Model owl: equivalentProperty sears :MfgPartNumber. amazon:PartNumber owl: equivalentProperty sears :MfgPartNumber. amazon:MPN owl: equivalentProperty sears :MfgPartNumber. amazon:Title owl:equivalentProperty sears:Title. amazon:Title owl:equivalentProperty sears:DescriptionName. amazon:Feature owl:equivalentProperty sears:ShortDescription. amazon:Feature owl:equivalentProperty sears:LongDescription. amazon:Manufacturer owl:equivalentProperty sears :BrandName. amazon:Offer owl:equivalentProperty sears:ProductDetail. amazon:Price owl:equivalentProperty sears:RegularPrice. amazon:Price owl:equivalentProperty sears:SalePrice.

6.4.4 Mappings Between HSO and GoodRelations

This section outlines the mappings between the HomeServices Ontology and GoodRela- tions ontology in Turtle form using the owl:equivalentProperty relation.

Mapping 6.7: Mapping between HSO and GoodRelations. gr:hasMakeAndModel owl:equivalentProperty gist :ProductOffering. gr:StockKeepingUnit owl:equivalentProperty gist :ID. gr:ProductOrServiceModel owl:equivalentProperty gist : ProductOffering. gr:hasMPN owl:equivalentProperty gist :ProductOffering. gr:hasName owl:equivalentProperty gist :name. gr:description owl:equivalentProperty gist:hasFeature. gr:hasManufacturer owl:equivalentProperty gist :producedBy. gr:description owl:equivalentProperty gist:Offering. gr:ProductOrService owl:equivalentProperty gist :ProductOffering. gr:weight owl:equivalentProperty gist:Weight. gr:Offering owl:equivalentProperty gist:Term. gr : hasEAN UCC 13 owl:equivalentProperty gist :hasBeenAllocated. gr : hasEAN UCC−13 owl:equivalentProperty gist:ID. gr:hasCurrencyValue− owl:equivalentProperty gist :currencyValue. Chapter 6. Serviced At Home 149

6.5 Testing the Mappings via SPARQL Queries

In order to utilize the tools provided by Hunch Manifest, Inc., the product data and mappings described in the previous section are expressed in a language that can be utilized with the AllegroGraph RDF data store. This section briefly outlines the queries that were written in SPARQL to test the mappings. Appendices D.5 and D.6 outline the settings used in AllegroGraph and the results returned from the SPARQL queries used to test the mappings, respectively. Our original intention of utilizing the HSO-Amazon and HSO-Sears mappings was to allow the inference of the bidirectional Amazon-Sears mappings from Section 6.4.3, but the reasoner tool in AllegroGraph could not make this inference. As a result of this limitation, only the direct 1:1 mappings between Amazon and Sears are tested via queries that compare and retrieve product information from both vendors. Thus, the following list summarizes the SPARQL queries that were run in AllegroGraph:

Section 6.5.1 describes a query to find the cheapest products offered by Sears and • Amazon.

Section 6.5.2 describes a query that finds the cheapest products offered by Sears • and Amazon based on a keyword.

Section 6.5.3 describes a query that finds the average price of products (specified • by keyword) offered by Sears and Amazon.

Section 6.5.4 describes a query that finds the average price of all products offered • by Sears and Amazon.

Section 6.5.6 describes a query that finds the average price of products offered by • Sears and Amazon based on a keyword.

Section 6.5.7 describes a query that finds the combined product attributes of a • product offered by both vendors.

Section 6.5.5 describes a federated query that combines the product data with • information from DBPedia. Chapter 6. Serviced At Home 150

6.5.1 Cheapest Products

The following query asks, “Who offers the cheapest products and what is the price?” The mapping between Amazon and Sears is indicated by matching the products with the sears:MfgPartNumber and amazon:MPN predicates; the query filters out the product with the lowest price and lists the manufacturer’s part number and the price. Table D.1 in Appendix D.6 lists the results of this query. PREFIX gist : PREFIX hso : PREFIX rdf : PREFIX rdfs : − PREFIX sears : PREFIX amazon : SELECT DISTINCT ?mfgno ?minprice WHERE ?searsproduct{ sears :MfgPartNumber ?mfgno. ?searsproduct sears :SalePrice ?searsprice. BIND ( xsd : decimal (?searsprice) AS ? minprice ) OPTIONAL ?amazonproduct{ amazon:MPN ?mfgno. ?amazontemp amazon:ListPriceFormattedPrice ?amazonprice . ?amazonproduct amazon: ListPrice ?amazontemp. BIND ( xsd : decimal ( substr (?amazonprice ,2)) AS ?otherprice) FILTER(?otherprice < ? minprice )

FILTER} (!bound (?otherprice)). } Code 6.8: SPARQL query to find the cheapest price of products.

6.5.2 Cheapest Products Based on Keyword

The following query asks, “Who offers the cheapest ’drill’ and what is the price?” Since product features are described in literals in both vendors’ tags, we will need to uti- lize the FILTER regex switch in the SPARQL query. The mapping between Amazon and Sears is indicated by matching the products with the sears:MfgPartNumber and amazon:MPN predicates; the query uses the regular expression REGEX switch in Chapter 6. Serviced At Home 151

SPARQL to filter out the cheapest products with the ‘drill’ keyword in its product name, and lists the manufacturer’s part number, price, and product name. Table D.2 in Ap- pendix D.6 lists the results of this query. PREFIX gist : PREFIX hso : PREFIX rdf : PREFIX rdfs : − PREFIX sears : PREFIX amazon : SELECT DISTINCT ?mfgno ?minprice ?prodTitle WHERE ?searsproduct{ sears :MfgPartNumber ?mfgno. ?searsproduct sears :SalePrice ?searsprice. BIND ( xsd : decimal (?searsprice) AS ? minprice ) ?searsproduct sears :DescriptionName ?prodTitle. OPTIONAL ?amazonproduct{ amazon:MPN ?mfgno. ?amazontemp amazon:ListPriceFormattedPrice ?amazonprice . ?amazonproduct amazon: ListPrice ?amazontemp. BIND ( xsd : decimal ( substr (?amazonprice ,2)) AS ?otherprice) FILTER(?otherprice < ? minprice ) ?amazonproduct amazon:Title ?prodTitle.

FILTER} (!bound (?otherprice)). FILTER regex(?prodTitle , ”drill”, ”i”). } Code 6.9: SPARQL query to find the cheapest price of products based on the ‘drill’ keyword.

6.5.3 Average Price of Products Based on Keyword

The following query returns the average price of products based on a keyword. In this case, it returns the average price for both companies, along with the product titles used. The mapping between Amazon and Sears is indicated by matching the products with the sears:DescriptionName and amazon:Title predicates, where the regular expres- sion REGEX switch in SPARQL filters out products that contain the keyword ‘drill’; the query then calculates the average price for the product per vendor, and lists the product Chapter 6. Serviced At Home 152

titles for both vendors and their respective average prices. Table D.3 in Appendix D.6 lists the results of this query. PREFIX gist : PREFIX hso : PREFIX rdf : PREFIX rdfs : − PREFIX sears : PREFIX amazon : SELECT ?searsTitle ?amazonTitle (AVG(?searsVal) AS ?searsavg) ( AVG(?amazonVal) AS ?amazonavg) WHERE ?searsproduct{ sears :DescriptionName ?searsTitle . ?searsproduct sears :SalePrice ?searsprice. BIND ( xsd : decimal (?searsprice) AS ? searsVal ) ?amazonproduct amazon:Title ?amazonTitle. ?amazontemp amazon:ListPriceFormattedPrice ?amazonprice. ?amazonproduct amazon: ListPrice ?amazontemp. BIND ( xsd : decimal ( substr (?amazonprice ,2)) AS ?amazonVal) FILTER regex(?searsTitle , ”drill”,”i”). FILTER regex(?amazonTitle, ”drill”, ”i”).

GROUPBY} ?searsTitle ?amazonTitle Code 6.10: SPARQL query to find the average price of products based on the ‘drill’ keyword.

6.5.4 Average Price of Products for Both Vendors

The following SPARQL query finds the average price of products, based on the model product number, for both vendors. The mapping between Amazon and Sears is indicated by matching the products with the sears:MfgPartNumber and amazon:MPN predi- cates; the manufacturer’s part numbers and average prices for both vendors are listed in the results. It should be noted that the matches between sears:MfgPartNumber and amazon:MPN may not give desired results due to the fact that the sears:MfgPartNumber predicate may contain the incorrect manufacturer’s part number, as previously discussed in Section 6.3.4. Table D.4 in Appendix D.6 lists the results of this query. Chapter 6. Serviced At Home 153

PREFIX gist : PREFIX hso : PREFIX rdf : PREFIX rdfs : − PREFIX sears : PREFIX amazon : SELECT ?mfgno (AVG(?searsVal) AS ?searsavg) (AVG(?amazonVal) AS ?amazonavg) WHERE ?searsproduct{ sears :MfgPartNumber ?mfgno. ?searsproduct sears :DescriptionName ?searsTitle . ?searsproduct sears :SalePrice ?searsprice. BIND ( xsd : decimal (?searsprice) AS ? searsVal ) ?amazonproduct amazon:MPN ?mfgno. ?amazonproduct amazon:Title ?amazonTitle. ?amazontemp amazon:ListPriceFormattedPrice ?amazonprice. ?amazonproduct amazon: ListPrice ?amazontemp. BIND ( xsd : decimal ( substr (?amazonprice ,2)) AS ?amazonVal)

GROUPBY} ?mfgno Code 6.11: SPARQL query to find the average price of products for both vendors.

6.5.5 Combination of Product Data with DBPedia Data

The following SPARQL query combines the product data with information from DB- Pedia15 to give a description of the product’s brand company that produces that was founded more than 10 years ago. The mapping between Amazon and Sears is indicated by matching the products with the sears:BrandName and amazon:Brand predicates to ensure that both products have the same brand; this query is then combined with a federated query that queries the DBPedia SPARQL endpoint to find companies that match the brand name and to filter out these results based on the companies’ found- ing year. The combined results are then filtered according to whether the companies were founded in the past ten years. Table D.7 in Appendix D.6 lists the results of this

15A LinkedData that extracts structured content from Wikipedia; DBpedia allows users to query rela- tionships and properties associated with Wikipedia resources, including links to other related datasets. http://www.http://dbpedia.org Chapter 6. Serviced At Home 154

query. We note that this query is not entirely correct since the company/brand names are appended to a fixed URI and the query does not ensure that the returned entities are actually companies. It is suggested to use either the dbpedia-owl:Organisation or dbpprop:companyName relations to verify that the returned entities in the federated query are actually companies listed in DBPedia. PREFIX gist : PREFIX hso : PREFIX rdf : PREFIX rdfs : − PREFIX sears : PREFIX amazon : PREFIX dbpedia owl : PREFIX dbpprop− :

SELECT ?productBrand ?foundingYear ?searstitle ?amazontitle ? brandDBPediaURI WHERE SELECT{{ ?productBrand ?searstitle ?amazontitle WHERE ?searsproduct{ sears :BrandName ?productBrand. ?searsproduct sears :DescriptionName ?searstitle . ?amazonproduct amazon:Brand ?productBrand. ?amazonproduct amazon:Title ?amazontitle. BIND(URI(CONCAT(”http://dbpedia . org/resource/” , ? productBrand)) AS ?brandDBPediaURI) . SERVICE }} SELECT DISTINCT ?foundingYear { WHERE ?brandDBPediaURI{ ?foundingYear . FILTER (?foundingYear >1500 && (2013 } ?foundingYear) >= 10 ) − ORDERBY DESC(?foundingYear)} ASC(?productBrand) LIMIT 1000 Code 6.12: Federated SPARQL query to combine the product with DBPedia data. Chapter 6. Serviced At Home 155

6.5.6 Average Price of Products for Both Vendors Based on

Keyword

The following SPARQL query finds the average price of products, based on the model product number and ‘drill’ keyword, for both vendors. The mapping between Amazon and Sears is indicated by matching the products with the sears:MfgPartNumber and amazon:MPN predicates. It should be noted that the matches between sears:MfgPartNumber and amazon:MPN may not give desired results due to the fact that the sears:MfgPartNumber predicate may contain the incorrect manufacturer’s part number, as previously discussed in Section 6.3.4. The regular expression REGEX switch in SPARQL filters out products that contain the keyword ‘drill,’ and the query then calculates the average price for the product per vendor, and lists the product titles for both vendors and their respective average prices. Table D.5 in Appendix D.6 lists the results of this query. PREFIX gist : PREFIX hso : PREFIX rdf : PREFIX rdfs : − PREFIX sears : PREFIX amazon : SELECT ?mfgno (AVG(?searsVal) AS ?searsavg) (AVG(?amazonVal) AS ?amazonavg) WHERE ?searsproduct{ sears :MfgPartNumber ?mfgno. ?searsproduct sears :DescriptionName ?searsTitle . ?searsproduct sears :SalePrice ?searsprice. BIND ( xsd : decimal (?searsprice) AS ? searsVal ) ?amazonproduct amazon:MPN ?mfgno. ?amazonproduct amazon:Title ?amazonTitle. ?amazontemp amazon:ListPriceFormattedPrice ?amazonprice. ?amazonproduct amazon: ListPrice ?amazontemp. BIND ( xsd : decimal ( substr (?amazonprice ,2)) AS ?amazonVal) FILTER (regex(?searsTitle , ”drill”,”i”) regex(?amazonTitle , ”drill”, ”i”)) | |

GROUPBY} ?mfgno Code 6.13: SPARQL query to find the average price of products for both vendors that are ‘drills.’ Chapter 6. Serviced At Home 156

6.5.7 All Known Product Attributes for a Combined Product

Model

Query 6.14 finds all of the known product attributes for a product match for both ven- dors. The match is based on the model product number (sears:MfgPartNumber and amazon:MPN), and the features and descriptions for both vendors are listed alongside the model number in the results. The results are then ordered according to the model product number. Note that there are two description variables for Sears; this is due to the inconsistent metadata stored in the ShortDescription and LongDescription tags: both of these tags contain Sears product attributes. Table D.6 in Appendix D.6 lists the results of this query. PREFIX gist : PREFIX hso : PREFIX rdf : PREFIX rdfs : − PREFIX sears : PREFIX amazon : SELECT ?mfgno ?amazonTitle ?amazondescription ?searsTitle ? searsdescription ?searsdescription2 WHERE ?searsproduct{ sears :MfgPartNumber ?mfgno. ?searsproduct sears :LongDescription ?searsdescription. ?searsproduct sears :ShortDescription ?searsdescription2. ?searsproduct sears :DescriptionName ?searsTitle . ?amazonproduct amazon:MPN ?mfgno. ?amazonproduct amazon:Feature ?amazondescription. ?amazonproduct amazon:Title ?amazonTitle.

ORDERBY} ?mfgno Code 6.14: SPARQL query to find all product attributes for a combined product model.

Each of the aforementioned queries produced successful results, as listed in Ap- pendix D.6. With exception to the federated query, all of the queries returned the expected product matches and price values from our sample dataset. As noted earlier, the federated query requires further refinement to ensure that the returned entities are Chapter 6. Serviced At Home 157 companies listed in DBPedia; since the query is still able to retrieve the company in- formation from the DBPedia SPARQL endpoint, we still consider this mapping between product information and DBPedia to be successful. We note that our primary goal of this portion of the project was to test the mappings to make sure they were correct, and remind the reader that the focus of the project was to outline the methodology taken to develop these mappings as a proof of concept for Hunch Manifest, Inc.

6.6 Discussion

The following section discusses the limitations of the applied methodologies in developing the vendor API ontologies and performing the data store queries.

6.6.1 Limitations of the Vendor Ontologies

Due to the fact that the vendor API ontologies were developed based on the returned XML product data, they are limited in only providing a glimpse of how the product information is structured. Since no additional semantics or axioms were included in the OWL ontologies, these vendor ontologies are limited in what can be done with them in terms of reasoning. For example, it is still possible to reason with these OWL vendor on- tologies to determine whether a class of products is part of another class, or to determine any subproperties of a given property.

6.6.2 Usage of RDF/XML to Test the Mappings

Since Hunch Manifest, Inc. strongly preferred the testing of mappings to be done in AllegroGraph, the ontologies needed to be converted from OWL into RDF/XML in Protege. Since there were no additional axioms in the OWL ontologies, we were able to test the mappings without issues; otherwise, they could not have been expressed in RDF/XML due to the lack of expressivity when one traverses down the Semantic Web Chapter 6. Serviced At Home 158

Stack from OWL to RDF (see Figure 6.3). It may become problematic in the future if axioms and/or more complex mappings are added to these vendor OWL ontologies and cannot be tested due to the expressive limitations of SPARQL and RDF/XML.

Figure 6.3: The Semantic Web Stack of the hierarchy of languages found in the Semantic Web; image from [7].

6.6.3 The Need for Adoption of Semantic Technologies in e-

Commerce

From this case study, we have seen how there is a lack of semantic technologies in e- commerce, particularly with vendors as large and well-known as Amazon and Sears. Since APIs provide a vendor with exposure to larger customer groups, the need for semantic technologies to be utilized in conjunction with the APIs has become prevalent, whether the semantic technologies adopted are with ontologies or the inclusion of Linked Data. With this case study, we have shown that there needs to be a greater push in e-commerce for more applications of semantic technologies to allow greater reuse of ontologies, deductive reasoning of rules in the product information data sets, and to Chapter 6. Serviced At Home 159 provide (home improvement) industries with a greater niche of customers.

6.6.4 No One General Methodology for Ontology Mapping

Furthermore, there does not appear to be one ‘general’ methodology for developing on- tology mappings. Since we were initially unsure of what kind of product information the vendor APIs utilized, we took longer than intended to determine what product con- cepts and properties could be mapped together between the two companies; as well, a more roundabout approach to developing the vendor OWL ontologies was taken due to changes in the project requirements and due to the lack of semantic technologies being used by the vendors. Despite these frustrations, the exploratory nature of this method- ology has enabled us to realize that the adoption of semantic web technologies within e-commerce should become more prevalent. As well, there needs to be a greater push for ‘mid-level’ ontologies that are slightly more specific than upper ontologies but are still general enough to allow vendor ontologies to map into them for greater reuse.

6.6.5 Existing Product Ontologies are Insufficient

Throughout the course of this project, we have seen that existing ‘product ontologies’, including GoodRelations, were not sufficient enough to be used in the mapping process to describe products. Existing product ontologies include the Product Types Ontology Extension for GoodRelations and the Google Product Taxonomy. Both of these ontolo- gies were insufficient to describe the actual features, not just the business aspects, of products and are described below. The Product Types Ontology is an extension of GoodRelations that provides a higher level of granularity to describe products. It provides product class definitions for every word found in the English Wikipedia pages [37]. The Product Types Ontology (PTO) uses the predefined GoodRelations properties for: Chapter 6. Serviced At Home 160

gr:category gr:hasStockKeepingUnit • • gr:color gr:height • • gr:condition • gr:isAccessoryOrSparePartFor • gr:depth • gr:isConsumableFor gr:hasEAN UCC-13 • • gr:isSimilarTo gr:hasGTIN-14 • • gr:hasMPN gr:weight • • gr:hasManufacturer gr:width • •

The pitfall of this “product ontology” is that, while it may have classes of product categories, product features such as whether a product is battery-powered, solar-powered, or requires an AC adapter, are not adequately described. Similarly, the Google Product Taxonomy16 is a tree of categories that aids users in classifying their products in the Google Merchant Centre17. The Google Shopping site allows consumers to easily find product listings on Google, where the product taxonomy lists all of the possible values the Google product category attribute can take on in order for an item to be displayed on Google Shopping. Like the Product Types Ontology, this Google Product Taxonomy only describes the categories under which products follow, and does not describe any product features.

6.7 Insights

From this case study, we have gathered additional insight on the ontology mapping pro- cess, along with the difficulties of developing semantics for vendor product specifications which lack the application of semantic formalisms within e-commerce. This project has outlined potential research and business areas that may be of interest within the ontology and e-commerce communities, as well as a starting point for vendors to adopt semantic 16https://support.google.com/merchants/answer/1705911?hl=en 17http://www.google.com/shopping Chapter 6. Serviced At Home 161 technologies. Chapter 7

Conclusion

Throughout this thesis we have outlined four different relationships that demonstrate how ontologies can be decomposed into modules, combined together, provide meaning to other unstructured ontologies, and used to define constructs in new ontologies. In doing so, we sought to answer the larger question of how relationships between ontologies can be axiomatized in first-order logic. We began with the DOLCE ontology that captures the ontological categories underly- ing natural language and human common sense. We presented our approach to modular- izing this ontology with the aid of translation definitions and theories found in COLORE,

and presented the following modules: Tdolce taxonomy, Tdolce mereology, Tdolce time mereology,

Tdolce present, Tdolce temporary parthood, and Tdolce constitution. We also introduced bipartite in- cidence structures that were used in the modularization process. Thus, we were able to verify the modules by showing that the models of the axioms are the intended models of the ontology. Next, we proceeded to determine additional relationships between the DOLCE and PSL ontologies based on similarities found between both ontologies’ notions of partici- pation. We combined theories of time points and time intervals together from COLORE

to create a new temporal theory that is used with the time interval version of Tpsl core to

162 Chapter 7. Conclusion 163 connect the DOLCE ontology with PSL. We were then able to show that theories from DOLCE can faithfully interpret theories found in PSL. We explored the notion of semantic augmentation with the CIMOSA framework and provided additional semantics to the framework constructs. We developed a first-order ontology for CIMOSA with the intention of linking the constructs with concepts and axioms found in PSL. In the process, however, we discovered that the technical jargon and ambiguous phrasing found in the CIMOSA documentation hindered our understand- ing of the intended semantics of the framework constructs; as well, the ambiguity and uncertainty surrounding the role of CIMOSA’s dimensions in the specification of their behavioural rule sets also prevented us from axiomatizing some of the constructs in first- order logic. We discussed the implications of these issues along with future areas of work pertaining to the looping rules found in CIMOSA. Finally, we developed and examined the applicability of mappings between two on- tologies where rich sets of axioms were not provided. We first needed to understand which concepts were common between Amazon, Sears, and the HSO ontologies before attempting mapping them together. This case study outlined and demonstrated the ad-hoc methodology required to map these two ontologies together. We discussed the barriers to developing seamless mappings between these vendor ontologies and the in- sights gained from our attempts of axiomatizing, however trivial they may be, the concept equivalences between them. Revisiting our initial goal of examining and axiomatizing the relationships found between ontologies, we can say that our ventures into examining these relationships have been rewarding. Not only have we completed a partial verification of the DOLCE ontology, we have provided an example of how translation definitions can be used to modularize and verify a widely used upper ontology. As well, we have explicitly outlined the relationships between DOLCE and PSL, and between DOLCE and time ontologies found in COLORE. However, while we have managed to axiomatize these relationships Chapter 7. Conclusion 164

found in the various ontologies, there are a few open issues in these case studies that need to be addressed in future work.

7.1 Open Issues

While we have attempted to axiomatize four selected ontology relationships of ontology decomposition, ontology composition, semantic augmentation, and ontology mapping, we have just barely scratched the surface of axiomatizing these relationships. There are many other ontologies to consider when examining these relationships with COLORE theories, such as the BFO, SUMO, and OpenCyc upper ontologies. As we have mentioned earlier, we have partially modularized the DOLCE ontol-

ogy. Since we only have the Tdolce taxonomy, Tdolce time mereology, Tdolce present, Tdolce mereology,

Tdolce temporary parthood, and Tdolce constitution modules completed, the verification of the

Tdolce dependence, Tdolce quality, and Tdolce quales modules still needs to be completed. A po-

tential issue that may arise with the verification of the Tdolce dependence module is how

it interacts with the Tdolce temporary parthood and Tdolce taxonomy modules since it combines

axioms from both. Furthermore, the faithful interpretations between Hdolce and Hperiods, and between Hperiods and Hcombined time have not been proven and need to be carried out. With respect to the proposed CIMOSA ontology, the current axiomatization has not been verified. In particular, the looping rules in Section 5.4.2 are similar to the graph- ical formalisms found in the IDEF3 and the UML modelling languages. Since IDEF3 allows cyclic orderings in its formalisms, additional work will need to be done to deter- mine how to represent these orderings axiomatically in CIMOSA; we may need to utilize

the subactivity occurrence soo(s, a) and subactivity precedence soo precedes(s1, s2, a) relations from PSL, or other precedence relations found in other process ontologies, to accurately axiomatize these looping rules. Another open issue with the axiomatization of the CIMOSA constructs is that we are unsure what is the correct characterization of the Chapter 7. Conclusion 165 intended models of the ontology. As discussed in Section 5.6, we are unsure of whether the proposed ontology’s axioms accurately reflect the semantics that are embedded in [1], [39], and [40], so the axioms need to be further refined and verified using a theorem prover such as Prover9.

7.2 Future Work

Future work should include considerations for developing a general methodology to design and test the correctness of translation definitions for defined relations. In particular, attention should be paid with regards to how one can develop translation definitions between two ontologies that correctly translate the meaning of one concept from one ontology into terminology used in the other. In Chapter3, the process of developing correct translation definitions between the DOLCE and PSL theories required trial and error to modify the translation definitions after iterations of theorem proving experiments failed to generate proofs. In addition, there needs to be a definitive distinction between the terminologies dis- tinguishing ontology relationships. While we have not made any distinctions between the terminologies found in the literature, we list some of the terms here as an example: bridge axioms, ontology alignment, ontology articulation, ontology integration, ontology mapping, ontology merging, ontology reconciliation, ontology transformation, and ontol- ogy translation. By making clear and agreed-upon distinctions between the terminologies used to describe ontology relationships, it further assists the IAOA and OntoIOp groups with creating open standards within the ontology community and to capture the general consensus of the meaning of these terms. Other directions for future work would be to utilize the proposed CIMOSA ontology to aid the IAOA with their goal of providing semantics to already-developed standards. The proposed CIMOSA ontology can be used as an example within the IAOA of de- Chapter 7. Conclusion 166 veloping a general methodology that could be adopted by others to provide semantics and additional meaning to standardized constructs found in other ISO documents. Ad- ditionally, another proposition would be to implement a methodology in place to utilize ontologies to remove the ambiguity found in standards documents which should be in place when the standards committee discusses and revises the various definitions of terms to include in the standard. Additionally, the development of a potential framework of negotiation that allows ontology designers to come up multiple axiomatizations that can be used and applied in different contexts. In the case of disagreement on how concepts are axiomatized, offering alternative axiomatizations provides users with a flexible ontology that suits their needs. A drawback of offering variations of axiomatizations, however, is that it may be too difficult to maintain the ontology if it contains many axioms. As well, it would be beneficial for the ontology community if a methodology for designing ontologies from scratch was developed for first-time ontology users. While both the Amazon and Sears API ontologies described in Chapter6 were minimal and did not contain any rich semantics, it would be beneficial if there were some guidelines to aid the process of adding additional semantics from raw XML product data. In addition, the development of a general product ontology that describes actual product features, in contrast to the GoodRelations ontology and its lack of relations to describe product features and not just attributes from a business perspective, would be greatly beneficial for product vendors to describe product information in a structured manner. Since both product ontologies developed for this thesis lack rich sets of axioms that describe product information, it would also be of interest to analyze whether the GoodRelations ontology is sufficient to be used to map other less-structured/weak ontologies together. Furthermore, we have outlined our extensive use of the COLORE repository to store the modules of DOLCE throughout this thesis. It would be valuable if the repository can be used in conjunction with automated reasoners: additional repository function- ality should be considered to facilitate the reuse of these COLORE theories, and the Chapter 7. Conclusion 167 storage and organization of lemmas and theory subsets to help improve theorem prover performance. As we have seen in Chapters3 and4, the techniques of using lemmas and excluding unnecessary axioms may allow an increase in efficiency of the automated reasoner, but require manual modifications to the experiment input files; the amount of manual labour involved to modify these input files does not abode well when theories have many axioms and makes it difficult to find relationships between the numerous the- ories stored in COLORE. By developing automated tools to assist us with discovering and proving meta-theoretic relationships of theories stored in COLORE, such tools would greatly assist us with this task of axiomatizing and analyzing these relationships between ontologies. With this in mind, another area of future work would be to extend the func- tionality of COLORE to for applications in ontology engineering and design, ontology evaluation, and semantic integration. Bibliography

[1] ESPRIT Consortium AMICE. CIMOSA: Open System Architecture for CIM. Re- search reports ESPRIT: AMICE. Springer-Verlag, 1993.

[2] Christoph Benzm¨ullerand Adam Pease. Higher-order Aspects and Context in SUMO. Web Semantics: Science, Services and Agents on the World Wide Web, 12:104–117, 2012.

[3] Michel Bidoit, Donald Sannella, and Andrzej Tarlecki. Architectural Specifications in CASL. Formal Asp. Comput., 13(3-5):252–273, 2002.

[4] Thomas Bittner, Maureen Donnelly, and Barry Smith. Endurants and Perdurants in Directly Depicting Ontologies. AI Commun., 17(4):247–258, December 2004.

[5] Olivier Bodenreider. Lexical, Terminological and Ontological Resources for Biological Text Mining, pages 43–66. Artech House, 2006.

[6] Stefano Borgo and Claudio Masolo. Foundational Choices in DOLCE. In Steffen Staab and Ruder Studer, editors, Handbook on Ontologies. Springer, second edition, 2009.

[7] Steve Bratt. Semantic Web: Linked Data on the Web. http://www.w3.org/ 2007/Talks/0130-sb-W3CTechSemWeb/, January 2007.

168 Bibliography 169

[8] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and Fran¸coisYergeau. Extensible Markup Language (XML) 1.0 (Fifth Edition). Technical report, W3C, November 2008.

[9] Keith Campbell. The Metaphysic of Abstract Particulars. Midwest Studies In Phi- losophy, 6(1):477–488, 1981.

[10] Namyoun Choi, Il-Yeol Song, and Hyoil Han. A Survey on Ontology Mapping. SIGMOD Rec., 35(3):34–41, September 2006.

[11] Dan Connolly. Gleaning Resource Descriptions from Dialects of Languages (GRDDL). http://www.w3.org/2004/01/rdxh/spec, September 2008.

[12] A.F. Cutting-Decelle, C.J. Anumba, A.N. Baldwin, N.M. Bouchlaghem, and Michael Gr¨uninger. Towards a Unified Specification of the Construction Process Informa- tion: The PSL Approach. In Proceedings of the International Conference ECPPM, Lisbonne, Portugal, September 2000.

[13] Manufacturing Systems Integration Division. Frequently Asked Questions (FAQ) - Process Specification Language (PSL). http://www.mel.nist.gov/psl/ faq.html, January 2007.

[14] Herbert B. Enderton. A Mathematical Introduction to Logic. Academic Press, 1972.

[15] William M. Farmer. An Infrastructure for Intertheory Reasoning. In CADE-17: Proceedings of the 17th International Conference on Automated Deduction, pages 115–131, London, UK, 2000. Springer-Verlag.

[16] Joint Center for Housing Studies. The U.S. Housing Stock: Ready for Renewal. Technical report, Harvard University, January 2013.

[17] Mark S. Fox and Michael Gr¨uninger.Enterprise Modeling. AI Magazine, 19(3):109– 121, 1998. Bibliography 170

[18] Andr´esGarc´ıa-Silva, Leyla Jael Garc´ıa-Castro,Alexander Garc´ıa-Castro, Oscar´ Cor- cho, and Asunci´onG´omez-P´erez.Building Ontologies from Folksonomies and Linked Data: Data Structures and Algorithms. 2012.

[19] N. Goodman. The Structure of Appearance. Number v. 53 in Boston Studies in the Philosophy of Science, The Structure of Appearance. R. Reidel Publishing Company, 1977.

[20] Thomas R. Gruber. Toward Principles for the Design of Ontologies Used for Knowl- edge Sharing. Int. J. Hum.-Comput. Stud., 43(5-6):907–928, 1995.

[21] Michael Gr¨uninger.The Ontological Stance for a Manufacturing Scenario. J. Cases on Inf. Techn., 11(4):1–25, 2009.

[22] Michael Gr¨uninger. Using the PSL Ontology. In Steffen Staab and Rudi Studer, editors, Handbook on Ontologies, International Handbooks on Information Systems, pages 423–443. Springer Berlin Heidelberg, 2009.

[23] Michael Gr¨uninger.Verification of the OWL-time Ontology. In Proceedings of the 10th International Conference on The Semantic Web - Volume Part I, ISWC’11, pages 225–240, Berlin, Heidelberg, 2011. Springer-Verlag.

[24] Michael Gr¨uningerand Carmen Chui. Mereological Bundles and Temporary Part- hood. Manuscript in preparation, 2013.

[25] Michael Gr¨uningerand Carmen Chui. Processes and Participation. Manuscript in preparation, 2013.

[26] Michael Gr¨uningerand Carmen Chui. Theory Foliations. Manuscript in preparation, 2013. Bibliography 171

[27] Michael Gr¨uninger and Mark S. Fox. The Role of Competency Questions in Enter- prise Engineering. In Proceedings of the IFIP WG5.7 Workshop on Benchmarking - Theory and Practice, 1994.

[28] Michael Gr¨uninger, Torsten Hahmann, Ali Hashemi, and Darren Ong. Ontology Verification with Repositories. In FOIS, pages 317–330, 2010.

[29] Michael Gr¨uninger, Torsten Hahmann, Ali Hashemi, Darren Ong, and Atalay Ozg¨ovde.¨ Modular First-Order Ontologies via Repositories. Applied Ontology, 7(2):169–209, 2012.

[30] Michael Gr¨uningerand Joseph B. Kopena. Semantic Integration Through Invariants. AI Mag., 26(1):11–20, March 2005.

[31] Michael Gr¨uningerand Christopher Menzel. The Process Specification Language (PSL) Theory and Applications. AI Mag., 24(3):63–74, September 2003.

[32] Michael Gr¨uningerand Darren Ong. Verification of Time Ontologies with Points and Intervals. In TIME, pages 31–38, 2011.

[33] Harry Halpin and Ian Davis. GRDDL Primer. http://www.w3.org/TR/ grddl-primer/, June 2007.

[34] Ali Hashemi. Using Repositories for Ontology Design and Semantic Mapping. Mas- ter’s thesis, University of Toronto, Department of Mechanical and Industrial Engi- neering, Toronto, Canada, 2008.

[35] Patrick Hayes. A Catalog of Temporal Theories. Technical Report UIUC-BI-AI- 96-01, Beckman Institute and Departments of Philosophy and Computer Science, University of Illinois, 1996. Bibliography 172

[36] Martin Hepp. The GoodRelations User’s Guide. http:// wiki.goodrelations-vocabulary.org/index.php?title=

Documentation&oldid=2189, July 2012.

[37] Martin Hepp. The Product Types Ontology: High-precision identifiers for product types based on Wikipedia. http://www.productontology.org/, February 2013.

[38] Graeme Hirst. Ontology and the Lexicon. In Steffen Staab and Rudi Studer, editors, Handbook on Ontologies, International Handbooks on Information Systems, pages 209–230. Springer, 2004.

[39] International Organization for Standardization. ISO 19439:2006: Enterprise Inte- gration - Framework for Enterprise Modeling, 2006.

[40] International Organization for Standardization. ISO 19440:2007: Enterprise Inte- gration - Constructs for Enterprise Modeling, 2007.

[41] International Organization for Standardization. ISO 24707:2007: Information tech- nology - Common Logic (CL): A Framework for a Family of Logic-based Languages, 2007.

[42] Yannis Kalfoglou and Marco Schorlemmer. Ontology Mapping: The State of the Art. In Y. Kalfoglou, M. Schorlemmer, A. Sheth, S. Staab, and M. Uschold, edi- tors, Semantic Interoperability and Integration, number 04391 in Dagstuhl Seminar Proceedings, Dagstuhl, Germany, February 2005. Internationales Begegnungs- und Forschungszentrum f¨urInformatik (IBFI), Schloss Dagstuhl, Germany.

[43] Megan Katsumi and Michael Gr¨uninger.Theorem Proving in the Ontology Lifecycle. In KEOD, pages 37–49, 2010. Bibliography 173

[44] Saket Kaushik, Csilla Farkas, Duminda Wijesekera, and Paul Ammann. An Algebra for Composing Ontologies. In Proceedings of the 2006 Conference on Formal On- tology in Information Systems, pages 265–276, Amsterdam, The Netherlands, The Netherlands, 2006. IOS Press.

[45] Lina Khatib. Reasoning with Sequences of Intervals for Efficient Constraint Propa- gation. PhD thesis, Florida Institute of Technology, Melbourne, Florida, 1996.

[46] K. Kosanke, F. Vernadat, and M. Zelm. CIMOSA: Enterprise Engineering and Integration. Comput. Ind., 40(2-3):83–97, November 1999.

[47] Kurt Kosanke. CIMOSA - Overview and Status. Computers in Industry, 27(2):101 – 109, 1995.

[48] Oliver Kutz and Till Mossakowski. A Modular Consistency Proof for DOLCE. In AAAI, 2011.

[49] Peter B. Ladkin. Time Representation: A Taxonomy of Internal Relations. In AAAI, pages 360–366, 1986.

[50] Li Li and Yun Yang. Agent-based Ontology Mapping and Integration Towards Interoperability. Expert Systems, 25(3):197–220, 2008.

[51] Claudio Masolo, Stefano Borgo, Aldo Gangemi, Nicola Guarino, and Alessandro Oltramari. WonderWeb Deliverable D18 Ontology Library (Final). Technical report, IST Project 2001-33052 WonderWeb: Ontology Infrastructure for the Semantic Web, 2003.

[52] Claudio Masolo, Stefano Borgo, Aldo Gangemi, Nicola Guarino, and Alessandro Oltramari. DOLCE2.1-Lite-Plus Version 3.9 Documentation, July 2006.

[53] Dave McComb. gist Core 6.7. http://ontologies.semanticarts.com/ gist/gistCore6.7.owl, January 2013. Bibliography 174

[54] Natalya Noy, Tania Tudorache, Csongor Nyulas, and Mark Musen. The Ontology Life Cycle: Integrated Tools for Editing, Publishing, Peer Review, and Evolution Of Ontologies. AMIA Annu Symp Proc, 2010.

[55] Leo Obrst. Ontologies for Semantically Interoperable Systems. In Proceedings of the Twelfth International Conference on Information and Knowledge Management, CIKM ’03, pages 366–369, New York, NY, USA, 2003. ACM.

[56] Boyan A. Onyshkevych and Sergei Nirenburg. Lexicon, Ontology, and Text Meaning. In SIGLEX Workshop, pages 289–303, 1991.

[57] Claus Pahl, Veronica Gacitua-Decar, MingXue Wang, and Kosala Yapa Bandara. Ontology-based Composition and Matching for Dynamic Cloud Service Coordina- tion. Int. J. Metadata Semant. Ontologies, 6(3/4):195–206, July 2011.

[58] Barry Smith. On Classifying Material Entities in Basic Formal Ontology. In Inter- disciplinary Ontology. Proceedings of the Third Interdisciplinary Ontology Meeting., pages 1–13, Tokyo, 2012. Keio University Press.

[59] Geoff Sutcliffe. Geoff Sutcliffe’s Overview of Automated Theorem Proving. http:

//www.cs.miami.edu/˜tptp/OverviewOfATP.html, March 2001.

[60] L.W. Szczerba. Interpretability of Elementary Theories. In RobertE. Butts and Jaakko Hintikka, editors, Logic, Foundations of Mathematics, and Computability Theory, volume 9 of The University of Western Ontario Series in Philosophy of Science, pages 129–145. Springer Netherlands, 1977.

[61] Mike Uschold, Martin King, Stuart Moralee, and Yannis Zorgios. The Enterprise Ontology. Knowl. Eng. Rev., 13(1):31–89, March 1998. Bibliography 175

[62] J. van Benthem. The Logic of Time: A Model-Theoretic Investigation into the Varieties of Temporal Ontology and Temporal Discourse. Synthese Library. Springer, 1991.

[63] Francois Vernadat. The CIMOSA Languages. Handbook on Architectures of Infor- mation Systems – International Handbooks on Information Systems, P. Bernus et

al., Springer-Verlag, Heidelberg, pages 243–263, 1998.

[64] Evelyne Viegas, Boyan Onyshkevych, Victor Raskin, and Sergei Nirenburg. From Submit To Submitted Via Submission: On Lexical Rules In Large-Scale Lexicon Acquisition. In Proceedings of the 34th annual meeting on Association for Computa- tional Linguistics, ACL ’96, pages 32–39, Stroudsburg, PA, USA, 1996. Association for Computational Linguistics.

[65] Gio Wiederhold. An Algebra for Ontology Composition. In Proceedings of 1994 Monterey Workshop on Formal Methods, pages 56–61, 1994.

[66] Martin Zelm, Fran¸coisB. Vernadat, and Kurt Kosanke. The CIMOSA Business Modelling Process. Comput. Ind., 27(2):123–142, October 1995.

[67] Antoine Zimmermann, Markus Kr¨otzsch, J´erˆomeEuzenat, and Pascal Hitzler. For- malizing Ontology Alignment and its Operations with Category Theory. In Proceed- ings of the 2006 conference on Formal Ontology in Information Systems: Proceedings

of the Fourth International Conference (FOIS 2006), pages 277–288, Amsterdam, The Netherlands, The Netherlands, 2006. IOS Press. Glossary

API An Application Programming Interface is a specification of how software compo- nents should interact with each other. In the context of web development, an API is a set of Hypertext Transfer Protocol (HTTP) request messages, along with a definition of the structure of response messages, which is usually in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format. 127, 128, 130–132, 134, 143, 157–159, 166 architectural specification Adopted from [3] and [48], a method of describing the modular structure found in software systems. It consists of list of unit declarations and unit terms that describe how modules are combined. 32, 176 automated theorem proving Automated theorem proving deals with the develop- ment of computer software that shows some statement, a conjecture, is a logical consequence of a set of statements, the axioms and hypotheses. ATP systems are capable of solving difficult problems under the aid of domain experts, and require problems to be written in a logical form in order to output proofs. Additional information can be found in [59]. 182

BFO The Basic Formal Ontology is a small, upper level ontology, developed by Barry Smith and Pierre Grenon, that consists of sub-ontologies at different levels of granu- larity. These sub-ontologies are divided into two categories: continuant (snapshot) ontologies, and occurrent (spanning) ontologies. 69, 70, 164

CASL The Common Algebraic Specification Language a general-purpose specification language based on first-order logic with induction, with support for partial functions and subsorting. It comprises of basic specifications (for the specification of single software modules), structured specifications (for the modular specification of mod- ules), architectural specifications (for the prescription of the structure of implemen- tations), and specification libraries (for storing specifications distributed over the Internet). Additional information can be found via http://www.informatik. uni-bremen.de/cofi/wiki/index.php/CASL.9, 23, 24, 33, 44

CIMOSA The Computer Integrated Manufacturing Open System Architecture mod- elling framework represents the business operations in the form of processes and allows the creation of executable enterprise models in computer integrated manu- facturing (CIM) programs. It was developed in 1992 and has been standardized by

176 Glossary 177

the ISO since 2006. Its construct specification can be found in [39] and [40].4–7, 91–96, 102–107, 117–122, 163–165

CLIF The Common Logic Interchange Format is one of the three standardized syntaxes found in the ISO 24707:2007 document for the Common Logic framework. Its syn- tax consists of quantified sentences, Boolean sentences, names for relations, func- tions, and individuals, and sequence names; as well, CLIF contains a vocabulary (a set of names and sequence names), and an interpretation of that vocabulary. For example, to say the following sentence, “A cat is on a mat,” we can write this in Common Logic as (exists ((x Cat) (y Mat)) (On x y)), which reads as “there exists a cat ‘x’ and a mat ‘y’, where ‘x’ is on ‘y”’.8–10, 33, 68

COLORE The COmmon Logic Ontology Repository is an open repository of first-order ontologies that serves as a test bed for ontology evaluation and integration tech- niques, and that can support the design, evaluation, and application of ontologies in first-order logic. All ontologies are specified using Common Logic (ISO 24707), which is a standardized logical language for the specification of first-order ontolo- gies and knowledge bases.3,6,7, 10, 12, 15, 18, 33, 35, 38, 39, 43, 45, 49, 51, 55–57, 62, 68–72, 74, 77, 79, 80, 82, 84, 87, 88, 106, 107, 117, 162–164, 166, 167, 192

Common Logic Common Logic is a standardized logical language designed for the specification of first-order ontologies and knowledge bases, and its details can be found in the ISO 24707:2007 document [41]. It consists of three dialects: the Conceptual Graph Interchange Format (CGIF), the Common Logic Interchange Format (CLIF), and the Extended Common Logic Markup Language (XCL).9, 10, 18, 25

completeness The derivation of all logically valid implications through reasoning. 10

conservative extension Adopted from [14], T2 is a conservative extension of T1 iff for any sentence σ (T1), ∈ L

T2 = σ iff T1 = σ | | . 11 conservativity triangle Adopted from [48], a graphical representation of relative con- 00 sistency proofs, where the given theories T , T 0, and T and signature morphisms 0 0 00 0 σ : T T , ι1 : T T and ι2 : T T , such that T is a conservativity triangle → → → and is consistent. If ι1 is conservative (definitional) and σ is a theory interpretation, then ι2 is conservative and T is consistent. 32

Cyc A proprietary artificial intelligence project developed by Cycorp, Inc. that con- sists of an ontology and a knowledge base of everyday common sense knowledge that is used to perform human-like reasoning. Parts of the project are released as OpenCyc. 181 Glossary 178

definable equivalence Adopted from [29], two theories, T1 and T2, are definably equiv- alent iff T1 is faithfully interpretable in T2, and T2 is faithfully interpretable in T1. 14

DOLCE The Descriptive Ontology for Linguistic and Cognitive Engineering is the first module of the WonderWeb foundational ontologies library that aims at capturing the ontological categories underlying natural language and human common sense. 3,5–9, 17, 20, 23–33, 35, 39, 43–45, 49, 51, 52, 55, 57, 59, 62–64, 68–73, 78, 82, 84, 85, 87, 88, 162–166, 181, 189 endurant In the philosophical sense, endurants are entities that exist in full in every instant that they exist [4]. 20, 24, 27–30, 51, 54, 56, 57, 68, 69, 181 extension Adopted from [14], let T1 and T2 be two first-order theories such that Σ(T1) ⊆ Σ(T2). T2 is an extension of T1 iff for any sentence σ (T1), ∈ L

if T1 = σ, then T2 = σ | | . 11 faithful interpretation Adopted from [29], an interpretation π of a theory T1 into a theory T2 is a faithful interpretation, if and only if, for any sentence σ (T1), L

T1 = σ T2 = π(σ) 6| ⇒ 6| . 14, 178

first-order logic First-order logic is a formal language used in mathematics, philosophy, linguistics, and computer science that contains a set of symbols and a syntax.1, 8–10, 18, 51, 70, 126

first-order theory Adopted from [14], a set of first-order sentences that are closed under logical entailment. 11 gist The gist ontology is minimalist upper ontology designed in OWL to have maximum coverage of typical business ontology concepts with the least amount of ambiguity. Additional information can be found via http://semanticarts.com/gist/. 126, 135, 138–141

GoodRelations The GoodRelations ontology is a lightweight ontology for annotating offerings and other aspects of e-commerce on the Web. It is written in OWL-DL and provides a standard vocabulary for product, price, store, and company data that can be embedded into Web pages. Additional information can be found via http: //www.heppnetz.de/ontologies/goodrelations/v1.html. 135, 138– 141, 148, 159 Glossary 179

graph database A database that uses graph structures with nodes, edges, and proper- ties to represent and store data. 127 GRDDL The Gleaning Resource Descriptions from Dialects of Languages is a markup format that is a W3C Recommendation which enables users to obtain RDF triples out of XML documents, including XHTML. Additional information can be found via http://www.w3.org/TR/grddl-primer/. 142, 143

hierarchy Adopted from [29], a hierarchy, H = , , is a partially ordered, finite set hH ≤i of theories = T1,...,Tn, such that: H 1. For all i and j, Σ(Ti) = Σ(Tj),

2. Ti Tj iff Tj is an extension of Ti, ≤ 3. Ti < Tj iff Tj is a non-conservative extension of Ti. . 10, 12–17, 37, 71–74, 77, 78, 80, 82, 88 HSO The Home Services Ontology is Hunch Manifest, Inc.’s ontology designed to inte- grate data from home improvement service providers and vendors’ websites. 126, 127, 130, 138, 146, 163

IAOA The International Association of Ontology and its Applications is a non-profit organization that promotes the interdisciplinary research and international collab- oration of the following fields: philosophical ontology, linguistics, logic, cognitive science, and computer science. The organization is interested in educating the com- munity on what ontologies are and how they can be effectively utilized, supporting the development of collaborations between research and industry, and supporting the publication of journals and books. Additional information can be found via http://www.iaoa.org/. 91, 165 IDEF The Integration DEFinition family of modelling languages is used in the field of systems and software engineering, which include functional modelling, data sim- ulation, object-oriented analysis/design, and knowledge acquisition. Additional information can be found via http://www.idef.com/. 120, 179 IDEF3 The Integrated DEFinition for Process Description Capture Method is a business process modelling method that is a scenario-driven process flow description capture method that represents: Process Flow Descriptions to capture the relationships between actions within • the context of a specific scenario, and Object State Transition to capture the description of the allowable states and • conditions. This method is part of the IDEF family of modelling languages in the field of systems and software engineering. Additional information can be found via http: //www.idef.com/IDEF3.htm. 122, 164 Glossary 180 intended structure Adopted from [23], an intended structure is a set of structures that characterizes the semantics of an ontology’s terminology. They are specified with respect to models of well-understood mathematical theories, such as partial ordering, geometries, and algebra. 17 interpretation Adopted from [29], an interpretation π of a theory T1 with the signature Σ(T1) into a theory T2 with the signature Σ(T2) is a function on the set of non- logical symbols of Σ(T1) and formulae in (T1), such that L

1. π assigns to a formula π∀ of (T2), in which at most the variable v1 occurs free, such that∀ L

T2 = ( v1)π∀ | ∃ 2. π assigns to each n-place relation symbol P a formula πP of (T2), in which L at most the variable v1, . . . , vn occur free.

3. For any sentence σ (T1), ∈ L T1 = σ T2 = π(σ) | ⇒ | . 13

ISO The International Organization for Standardization is an international standard- setting body composed of various national standards organizations. The organiza- tion mainly produces international standard documents, technical reports, techni- cal specifications, publicly available specifications, technical corrigenda, and guides. Additional information can be found via http://www.iso.org/. 92, 166 language Adopted from [14], the set of first-order formulae that only use the non-logical symbols in the signature Σ(T ). 11

Mace4 A program that searches for finite models of first-order formulas and can be used in conjunction with Prover9 to find a proof and counter-example. 16 non-conservative extension Adopted from [14], T2 is a non-conservative extension of T1 iff T2 is an extension of T1 and there exists a sentence σ Σ(T1) where ∈

T1 = σ and T2 = σ 6| | . 11

NSERC The Natural Sciences and Engineering Research Council of Canada is a gov- ernment agency that provides grants for research in the natural sciences and in engineering by supporting university students in their advanced studies, and en- couraging Canadian companies to participate and invest in postsecondary research projects. Additional information about NSERC can be accessed via their home page: http://www.nserc-crsng.gc.ca. 125 Glossary 181

OntoIOp The Ontology Integration and Interoperability is a working item proposed in ISO TC37/SC3 that is intended to support the specification of a formal language for enabling distributed knowledge representation in ontologies; as well, the intent is to achieve interoperability across ontologies, services and devices. Additional information can be accessed via their home page: http://ontoiop.org. 91, 165

OpenCyc The OpenCyc ontology is the open-source version of the Cyc ontology, which includes the entire Cyc ontology containing hundreds of thousands of terms, along with millions of taxonomic assertions relating the terms to each other. This version of Cyc does not contain the complex rules available in Cyc. Additional information about OntoIOp can be found via http://www.cyc.com/platform/opencyc. 69, 70, 164, 177

OWL The Web Ontology Language is a World Wide Web Consortium (W3C) knowl- edge representation language used for authoring ontologies that is characterized by formal semantics and RDF/XML-based serializations. There are three vari- ants of OWL, each of which have different levels of expressiveness: OWL-Lite, OWL-DL, and OWL Full. Additional information about OWL can be found via http://www.w3.org/TR/owl-ref/.8, 70, 126–128, 131, 145, 146, 157–159, 178 participation In the context of DOLCE, the authors of [51] indicate that there are endurants involved in an occurrence, so the notion of participation is not considered parthood. In DOLCE, participation is time-indexed in order to account for the varieties of participation in time, such as temporary participation and constant participation. 29, 181 perdurant In the philosophical sense, perdurants are entities that exist over successive temporal parts of phases [4]. 20, 27, 28, 30, 51, 54, 68, 69

Prover9 An automated theorem prover for first-order and equational logic. It is the successor of the Otter theorem prover.9, 16, 33, 49, 56, 57, 165

PSL Adapted from [12], the Process Specification Language is a neutral, interchange language that integrates multiple process-related applications throughout the man- ufacturing life cycle.3–6, 15, 18, 19, 69–72, 78–82, 85, 87, 88, 91, 97, 102–107, 110, 111, 113, 114, 116, 122, 162–165, 185, 187

RDF The Resource Description Framework is family of World Wide Web Consortium (W3C) specifications that are similar to conceptual modelling approaches, such as entity-relationship diagrams and class diagrams, that is based upon the notion of making statements about resources in the form of ‘subject-predicate-object’ ex- pressions known as ‘triples.’ The subject denotes the resource, and the predicate denotes the traits/aspects of the resource and expresses a relationship between the subject and object.8, 127, 128, 142, 143, 145, 146, 149, 157, 158, 181, 183, 211 reducibility A theory, T , is reducible to a set of theories T1, ..., Tn iff: Glossary 182

T faithfully interprets each theory Ti, and • T1 ... Tn faithfully interprets T • ∪ ∪ . 14

relative consistency proof Adopted from [15], within the Interactive Mathematical Proof System (IMPS), there is a set of theories deemed foundational and are re- garded or known to be consistent. Since all proofs begin with a foundational theory and any theory developed from another is a conservative extension of the original theory, all theories developed are consistent relative to the original foundational theory, thus all proofs generated are guaranteed to be consistent. 32

representation theorem In mathematics, a representation theorem is a theorem that states that every abstract structure with certain properties is isomorphic to a con- crete structure. 17

semantic augmentation In the context of the work done in this thesis, semantic aug- mentation means that constructs that have not been defined will be linked with con- cepts from already-defined theories and axioms found in ontologies in order to ben- efit from the reasoning capabilities of semantic technologies that utilize computer- interpretable ontology formats. “Mapping rules” were created with these first-order theories to define the CIMOSA terminologies using the PSL axioms.4, 89 semantic heterogeneity Semantic heterogeneity occurs when software applications and databases used by the data providers ascribe disparate meanings to the same terms or use distinct terms to convey the same meaning.3, 127 signature Adopted from [14], it is the non-logical lexicon, of a first-order theory T is denoted by Σ(T ). It is the set of all constant symbols, function symbols, and relation symbols that are used in T . 11

soundness The derivation of true statements through reasoning. 10

SPARQL The SPARQL Protocol and RDF Query Language is a query language for databases, able to retrieve and manipulate data stored in Resource Description Framework format. 128, 130, 145, 146, 149–153, 155, 157, 158, 214

strong ontology A strong ontology is characterized by the ability to characterize com- plex semantics/meaning in a set of axioms [55, 31].5

SUMO Adapted from [12], the Suggested Upper Merged Ontology is a neutral, inter- change language that integrates multiple process-related applications throughout the manufacturing life cycle. 69, 70, 164

TPTP The Thousands of Problems for Theorem Provers is a library of test problems for automated theorem proving (ATP) systems, and consists of: a comprehensive library of the ATP test problems, a comprehensive list of references and information Glossary 183

for each problem, arbitrary size instances of generic problems, a utility to convert the problems to existing ATP systems’ formats, general guidelines outlining the requirements for ATP system evaluation, and standards for input and output for ATP systems. 32

translation definition Adopted from [29]. Let T0 be a theory with the signature Σ(T0) and T1 be a theory with the signature Σ(T1), such that Σ(T0) Σ(T1) = . If there ∩ ∅ is an interpretation of T0 in T1, then there exists a set of sentences that axiomatizes the mapping, called a translation definition, in the language of L0 L1 of the form: ∪

( x¯)pi(¯x) Φ¯x ∀ ≡

where pi(¯x) is a relation symbol in L0 and (Φ¯x) is a formula in L1 whose only free variables arex ¯.6, 10, 15, 16, 165

Turtle The Terse RDF Triple Language is a format for expressing data in the RDF data model that uses triples, each of which consists of a subject, a predicate, and an object. Turtle groups three URIs to make a triple, and provides ways to abbreviate information by factoring out common portions of URIs. For example, to express that Mark Twain was the author of Huckleberry Finn, the triple would be written as: person:Mark Twain relation:author books:Huckleberry Finn. Additional information can be found via http://www.w3.org/TR/turtle/. 142, 146

UML The Unified Modelling Language is a general-purpose modelling language in the field of software engineering that is standardized in ISO/IEC 19501:2005. The Unified Modelling Language includes a set of graphic notation techniques to create visual models of object-oriented software-intensive systems. Additional information about UML can be found via http://www.uml.org/. 122, 164 unit declaration Adopted from [3], indicates the component modules required with specifications of each of them. 176 unit term Adopted from [3], descriptions of how modules are to be combined within an architectural specification. 176 weak ontology A weak ontology is characterized by the lack of the expressible or char- acterizable semantics and the ability to express very simple meaning; these include a collection of terms found in thesauri and dictionaries, as well as taxonomies and database schemas [55, 31].5

XML The Extensible Markup Language is a markup language defines rules for encoding documents in a format that is both human-readable and machine-readable. It was designed with the intent to emphasize simplicity, generality, and usability over the Internet [8]. It is a textual data format that used to represent arbitrary data Glossary 184

structures as well as documents. Additional information about the specifications of XML can be found in [8]. 127, 128, 131, 132, 134, 135, 142–145, 157, 158, 166, 181, 211 Appendix A

Additional Background Information

A.1 The PSL Ontology

This section contains additional information about the PSL ontology.

A.1.1 Axioms of Tpsl core

The following are the axioms of Tpsl core:

( x (activity(x) activity occurrence(x) timepoint(x) object(x))). (A.1.1) ∀ ∨ ∨ ∨

( t1 t2 (before(t1, t2) timepoint(t1) timepoint(t2))). (A.1.2) ∀ ∀ ⊃ ∧ ( t1 t2 (timepoint(t1) timepoint(t2) ∀ ∀ ∧ ⊃ t1 = t2 before(t1, t2) before(t2, t1))). (A.1.3) ∨ ∨

( t1 before(t1, t1)). (A.1.4) ∀ ¬

( t1 t2 t3 (before(t1, t2) before(t2, t3) before(t1, t3))). (A.1.5) ∀ ∀ ∀ ∧ ⊃

( t (timepoint(t) t! = ”inf ” before(”inf ”, t))). (A.1.6) ∀ ∧ − ⊃ −

( t (timepoint(t) t! = ”inf + ” before(t, ”inf + ”))). (A.1.7) ∀ ∧ ⊃

185 Appendix A. Additional Background Information 186

( t (timepoint(t) t = ”inf ” ∀ ∧ 6 − ⊃ ( u (before(”inf ”, u) before(u, t))))). (A.1.8) ∃ ¬ ∧ ( t (timepoint(t) t = ”inf + ” ∀ ∧ 6 ⊃ ( u (before(t, u) before(u, ”inf + ”))))). (A.1.9) ∃ ∧ ( x ((activity(x) (activity occurrence(x) ∀ ⊃ ¬ ∨ object(x) timepoint(x))) (activity occurrence(x) ∨ ∧ ⊃ (object(x) timepoint(x))) (object(x) timepoint(x)))). (A.1.10) ¬ ∨ ∧ ⊃ ¬

( a occ (occurrence of(occ, a) activity(a) activity occurrence(occ))). (A.1.11) ∀ ∀ ⊃ ∧

( occ (activity occurrence(occ) ( a(activity(a) occurrence of(occ, a))))). (A.1.12) ∀ ⊃ ∃ ∧ ( occ a1 a2 (occurrence of(occ, a1) ∀ ∀ ∀ ∧ occurrence of(occ, a2) a1 = a2)). (A.1.13) ⊃ ( a x (occurrence of(x, a) object(x) ∀ ∀ ∨ ⊃ timepoint(beginof(x)) timepoint(endof(x)))). (A.1.14) ∧

( x (activity occurrence(x) object(x) beforeEq(beginof(x), endof(x)))). (A.1.15) ∀ ∨ ⊃ ( x occ t (participates in(x, occ, t) ∀ ∀ ∀ ⊃ object(x) activity occurrence(occ) timepoint(t))). (A.1.16) ∧ ∧

( x occ t (participates in(x, occ, t) at(x, t) is occurring at(occ, t))). (A.1.17) ∀ ∀ ∀ ⊃ ∃ ∧

( t1 t2 (beforeEq(t1, t2) timepoint(t1) ∀ ∀ ≡ ∧ timepoint(t2) (before(t1, t2) t1 = t2))). (A.1.18) ∧ ∨

( t1 t2 t3 (betweenEq(t1, t2, t3) beforeEq(t1, t2) beforeEq(t2, t3))). (A.1.19) ∀ ∀ ∀ ≡ ∧

( x t ( at(x, t) object(x) betweenEq(beginof(x), t, endof(x)))) (A.1.20) ∀ ∀ ∃ ≡ ∧

( occ t (is occurring at(occ, t) betweenEq(beginof(occ), t, endof(occ)))). (A.1.21) ∀ ∀ ≡ Appendix A. Additional Background Information 187

Tactocc

Tcomplex

Tatomic Tdisc state

Tsubactivity Tduration Tocctree

Tpsl core Figure A.1: The core theories of the PSL Ontology, adapted from [22]. Solid lines indicate conservative extension, while dashed lines indicate an extension that is not conservative.

A.1.2 Core Theories of the PSL Ontology

Figure A.1 outlines the core theories of the PSL ontology.

A.2 PSL Lexicon

Table A.1 outlines the lexicon used in the core theories of the PSL ontology. Appendix A. Additional Background Information 188

Table A.1: Lexicon used in the core theories of the PSL ontology.

Theory Predicate Description

Tpsl core activity(a) a is an activity activity occurrence(o) o is an activity occurrence object(x) x is an object occurrence of(o, a) o is an occurrence of a beginof(o) the beginning timepoint of o endof(o) the ending timepoint of o before(t1, t2) timepoint t1 precedes timepoint t2 on the timeline Tsubactivity subactivity(a1, a2) a1 is a subactivity of a2 primitive(a) a is a minimal element of the subactiv- ity ordering Tatomic atomic(a) a is either primitive or a concurrent ac- tivity conc(a1, a2) the activity that the concurrent com- position of a1 and a2 Tocctree legal(s) s is an element of a legal occurrence initial(s) s is the root of an occurrence tree earlier(s1, s2) s1 precedes s2 in an occurrence tree Tdiscstate holds(f, s) the fluent f is true immediately after the activity occurrence s prior(f, s) the fluent f is true immediately before the activity occurrence s Tcomplex min precedes(s1, s2, a) The atomic subactivity occurrence s1 precedes the atomic subactivity s2 in an activity tree for a root(s, a) the atomic subactivity occurrence s is the root of an activity tree for a Tactocc subactivity occurrence(o1, o2) o1 is a subactivity occurrence of o2 root occ(o) the initial atomic subactivity occur- rence of o leaf occ(s, o) s is the final atomic subactivity occur- rence of o Tduration timeduration(d) d is a time duration duration(t1, t2) the time duration whose value is the ’distance’ from timepoint t1 to time- point t2 lesser(d1, d2) the linear ordering relation over time durations Appendix B

Additional DOLCE Information

B.1 DOLCE Axioms from WonderWeb

The following DOLCE axioms are from the original WonderWeb document [51].

Parthood Argument Restrictions P (x, y) (AB(x) PD(x)) (AB(y) PD(y)) (Ad1) ⊃ ∨ ∧ ∨ P (x, y) (PD(x) PD(y)) (Ad2) ⊃ ≡ P (x, y) (AB(x) AB(y)) (Ad3) ⊃ ≡ (P (x, y) SB(R, φ) X(φ)) (φ(x) φ(y)) (Ad4) ∧ ∧ ⊃ ≡ Ground Axioms (AB(x) PD(x)) P (x, x) (Ad5) ∨ ⊃ (P (x, y) P (y, x)) x = y (Ad6) ∧ ⊃ (P (x, y) P (y, z)) P (x, z) (Ad7) ∧ ⊃ ((AB(x) PD(x)) P (x, y)) z (P (z, x) O(z, y)) (Ad8) ∨ ∧ ¬ ⊃ ∃ ∧ ¬ ( x φ(x) ( x (φ(x) AB(x)) x (φ(x) PD(x)))) y (y = σxφ(x)) (Ad9) ∃ ∧ ∀ ⊃ ∨ ∀ ⊃ ⊃ ∃

189 Appendix B. Additional DOLCE Information 190

Temporary Parthood Argument Restrictions P (x, y, t) (ED(x) ED(y) T (t)) (Ad10) ⊃ ∧ ∧ P (x, y, t) (PED(x) PED(y)) (Ad11) ⊃ ≡ P (x, y, t) (NPED(x) NPED(y)) (Ad12) ⊃ ≡ Ground Axioms (P (x, y, t) P (y, z, t)) P (x, z, t) (Ad13) ∧ ⊃ (ED(x) ED(y) PRE(x, t) PRE(y, t) P (x, y, t)) z (P (z, x, t) O(z, y, t)) ∧ ∧ ∧ ∧ ¬ ⊃ ∃ ∧ ¬ (Ad14) ( x φ(x) x (φ(x) ED(x))) y (y = σtexφ(x)) (Ad15) ∃ ∧ ∀ ⊃ ⊃ ∃ Links With Other Primitives (ED(x) PRE(x, t)) P (x, x, t) (Ad16) ∧ ⊃ P (x, y, t) (PRE(x, t) PRE(y, t)) (Ad17) ⊃ ∧ P (x, y, t) t0 (P (t0, t) P (x, y, t0)) (Ad18) ⊃ ∀ ⊃ (PED(x) P (x, y, t)) x S< y, t > (Ad19) ∧ ⊃ ⊆ Constitution Argument Restrictions K(x, y, t) ((ED(x) PD(x)) (ED(y) PD(y)) T (t)) (Ad20) ⊃ ∨ ∧ ∨ ∧ K(x, y, t) (PED(x) PED(y)) (Ad21) ⊃ ≡ K(x, y, t) (NPED(x) NPED(y)) (Ad22) ⊃ ≡ K(x, y, t) (PD(x) PD(y)) (Ad23) ⊃ ≡ Ground Axioms K(x, y, t) K(y, x, t) (Ad24) ⊃ ¬ (K(x, y, t) K(y, z, t)) K(x, z, t) (Ad25) ∧ ⊃ Links With Other Primitives K(x, y, t) (PRE(x, t) PRE(y, t)) (Ad26) ⊃ ∧ K(x, y, t) t (P (t0, t) K(x, y, t0)) (Ad27) ≡ ∀ ⊃ (K(x, y, t) PED(x)) x S< y, t > (Ad28) ∧ ⊃ ≈ (K(x, y, t) P (y0, y, t)) x0 (P (x0, x, t) K(x0, y0, t)) (Ad29) ∧ ⊃ ∃ ∧ Appendix B. Additional DOLCE Information 191

Links Between Categories GK(NAP O, M) (Ad30) GK(AP O, NAP O) (Ad31) GK(SC, SAG) (Ad32)

General Properties K(x, x, t) (Td1) ¬ SK(φ, ψ) SD(φ, ψ) (Td2) ⊃ GK(φ, ψ) GD(φ, ψ) (Td3) ⊃ (SK(φ, ψ) SK(ψ, ρ) DJ(φ, ρ)) SK(φ, ρ) (Td4) ∧ ∧ ⊃ (GK(φ, ψ) GK(ψ, ρ) DJ(φ, ρ)) GK(φ, ρ) (Td5) ∧ ∧ ⊃ Participation Argument Restrictions PC(x, y, t) (ED(x) PD(y) T (t)) (Ad33) ⊃ ∧ ∧ Existential Axioms (PD(x) PRE(x, t)) y (PC(y, x, t)) (Ad34) ∧ ⊃ ∃ ED(x) y t (PC(x, y, t)) (Ad35) ⊃ ∃ ∃ Links With Other Primitives PC(x, y, t) (PRE(x, t) PRE(y, t)) (Ad36) ⊃ ∧ PC(x, y, t) t0 (P (t0, t) PC(x, y, t0)) (Ad37) ≡ ∀ ⊃ Ground Properties PC(x, x, t) (Td6) ¬ PC(x, y, t) PC(y, x, t) (Td7) ⊃ ¬ Being Present Argument Restrictions (ED(x) PD(x) Q(x)) t (PRE(x, t)) (Td15) ∨ ∨ ⊃ ∃ ((PED(x) PQ(x)) PRE(x, t)) s (PRE(s, x, t)) (Td16) ∨ ∧ ⊃ ∃ Appendix B. Additional DOLCE Information 192

Ground Axioms (PRE(x, t) P (t0, t)) PRE(x, t0) (Td17) ∧ ⊃ PRE(s, x, t) PRE(x, t) (Td18) ⊃

B.2 Additional DOLCE Axioms

B.2.1 Axiomatization of T dolce present∗

Figure B.1 lists all of the axioms found in Tdolce present ; as well, the axioms can be found ∗ in COLORE1.

( x)(ED(x) PD(x)) ( t) PRE(x, t) (B.2.1) ∀ ∨ ⊃ ∃

( x, t, t1) PRE(x, t) P (t1, t) PRE(x, t1) (B.2.2) ∀ ∧ ⊃

( x, t) PRE(x, t) T (t) (B.2.3) ∀ ⊃

( x, t, t1, t2) PRE(x, t1) PRE(x, t2) SUM(t, t1, t2) PRE(x, t) (B.2.4) ∀ ∧ ∧ ⊃

Figure B.1: Axioms of Tdolce present . ∗

1http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_ present/dolce_present_star.clif Appendix C

Additional CIMOSA Information

C.1 Axiomatizations of PSL Constructs Used in the

CIMOSA Ontology

The following axiomatizations of PSL constructs are from complex.clif in the PSL hierarchy in COLORE. Root Activity in Occurrence Trees ( cl comment ”Root occurrences in the activity tree correspond to −atomic subactivity occurrences of the activity.”)

(forall (a s) ( i f ( root s a ) (exists (a1) (and (subactivity a1 a) (atocc s a1)))))

Leaf Nodes in Occurrence Trees ( cl comment ”An occurrence is the leaf of an activity tree if −and only if there exists an earlier atomic subactivity occurrence but there does not exist a later atomic subactivity occurrence.”)

193 Appendix C. Additional CIMOSA Information 194

(forall (s a) (iff (leaf s a) (and (or (rootsa) ( min precedes s1 s a)) (not (exists (s2) ( min precedes s s2 a))))))

Precedence in Occurrence Trees ( cl comment ”Activity trees are subtrees of the occurrence tree. −”)

(forall (s1 s2 a) ( i f ( min precedes s1 s2 a) (precedes s1 s2)))

C.2 Common Logic Version of the CIMOSA Ontol-

ogy

( cl text cimosa − ( cl comment ”Sources: ISO 19439:2006, ISO 19440:2007, −Vernadat1998.”) ( cl comment ”Comment: The following ontology is created to −describe the behavioural rule set found in CIMOSA.”)

( cl comment ”Import the PSL Core ontology since the CIMOSA −ontology uses PSL constructs.”) ( cl imports psl core ) − − ( cl comment ”Import the complex subtheory of the PSL ontology −since the CIMOSA ontology uses PSL constructs.”) ( cl imports complex) − ( cl comment ”===== Mappings =====”) ( cl −comment ”Map between CIMOSA and PSL constructs .”) ( cl −comment ”A business process in CIMOSA is an activity in PSL. −”) ( f o r a l l ( x ) ( i f ( b u s i n e s s process x)(activity x))) Appendix C. Additional CIMOSA Information 195

( cl comment ”An enterprise activity in CIMOSA is an activity in PSL− . ” ) ( f o r a l l ( x ) ( i f (enterprise activity x)(activity x)))

( cl comment ”An enterprise function in CIMOSA is an activity in PSL− . ” ) ( f o r a l l ( x ) ( i f (enterprise function x)(activity x)))

( cl comment ”An enterprise object in CIMOSA is an object in PSL. −”) ( f o r a l l ( x ) ( i f (enterprise object x)(object x)))

( cl comment ”An event in CIMOSA is an activity in PSL.”) ( f o− r a l l ( x ) ( i f (event x)(activity x)))

( cl comment ”An occurrence in CIMOSA is an activity occurrence −in PSL . ” ) ( f o r a l l ( x ) ( i f (occurrence x)(activity occurrence x)))

( cl comment ”All enterprise functions are business processes or −enterprise activities.”)

( f o r a l l ( x ) ( i f (enterprise f u n c t i o n x ) (or (business process x)(enterprise activity x)) ))

( cl comment ”===== Behavioural Rule Set =====”) ( cl −comment ”Ending Status (ES) Values”) ( cl −comment ”end s t a t 1 is a constant/value”) (forall− (o x) ( i f (occurrence of o (enterprise function x)) ( holds e n d s t a t 1 o ) ) )

( cl comment ”Process Triggering Rules”) ( cl −comment ”WHEN (START WITH event i AND event j ) DO EF1” ) (forall− (o1 o2 x f) − − ( i f (and (occurrence of o1 (domain process x ) ) (root o2 o1) (occurrence o f o2 ( e n t e r p r i s e function f))) Appendix C. Additional CIMOSA Information 196

(exists (o3 o4 i j) (and (precedes o3 o2)(precedes o4 o2 ) (occurrence o f o3 ( activity i))( o c c u r r e n c e o f o4 ( activity j))))))

( cl comment ”WHEN (START) DO EF1” ) ( cl −comment ”OR for all business processes , there exist a parent −p r o c e s s implicit that o precedes o1 because of root”) (forall (o1− x) ( i f (occurrence of o1 (business p r o c e s s x ) ) (exists (o y) (and (root o o1)(occurrence o f o ( business process y))(precedes o o1))) ))

( cl comment ”Forced Sequential Rules”) ( cl −comment ”WHEN (ES(EFx) = ANY) DO EFy” ) ( cl −comment ”Note: ANY is a reserved key word.”) (forall− (o1 x) ( i f (and (holds ”ANY” o1) (occurrence of o1 (enterprise function x))) (exists (o2 y) (and (occurrence o f o2 ( e n t e r p r i s e function y)) (precedes o1 o2)))))

( cl comment ”Conditional Sequential Rules”) ( cl −comment ”WHEN (ES(EF1) = end s t a t 1 ) DO EF2” ) ( cl −comment ”If the enterprise function x has an ending status −value of end stat 1, and o1 is an occurrence of x, then there exists an o2 which is an occurrence of enterprise function y that occurs after o1.”) ( cl comment ”end stat 1 , end stat 2, etc. are values.”) (forall− (o1 x) ( i f (and (holds end s t a t 1 o1 ) (occurrence of o1 (enterprise function x))) (exists (o2 y) (and (occurrence o f o2 ( e n t e r p r i s e function y)) (precedes o1 o2))))) Appendix C. Additional CIMOSA Information 197

( cl comment ”WHEN (ES(EF1) = end s t a t 2 ) DO EF3” ) (forall− (o2 x) ( i f (and (holds end s t a t 2 o2 ) (occurrence of o2 (enterprise function x))) (exists (o3 y) (and (occurrence o f o3 ( e n t e r p r i s e function y)) (precedes o2 o3)))))

( cl comment ”WHEN (ES(EF1) = end s t a t 3 ) DO EF4” ) (forall− (o3 x) ( i f (and (holds end s t a t 3 o3 ) (occurrence of o3 (enterprise function x))) (exists (o4 y) (and (occurrence o f o4 ( e n t e r p r i s e function y)) (precedes o3 o4)))))

( cl comment ”Spawning Rules”) ( cl −comment ”Asynchronous Spawning”) ( cl −comment ”WHEN (ES(EF1) = value ) DO EF2 & EF3 & EF4” ) ( cl −comment ”value is a specific ending status. We do not know −in which order EF2, EF3, and EF4 occurs.”) (forall (o1 x) ( i f (and (holds value o1) (occurrence of o1 (enterprise function x))) (exists (o2 o3 o4 t y z) (and (occurrence o f o2 ( e n t e r p r i s e function t)) (occurrence o f o3 ( e n t e r p r i s e function y)) (occurrence o f o4 ( e n t e r p r i s e function z)) (precedes o1 o2) (precedes o1 o3) (precedes o1 o4)))))

( cl comment ”Synchronous Spawning”) ( cl −comment ”WHEN (ES(EF1) = value ) DO SYNC (EF2 & EF3 & EF4) ” ) ( cl −comment ”Note: EF2, EF3 and EF4 start at the same time point −.”) (forall (o1 x) ( i f (and (holds value o1) (occurrence of o1 (enterprise function x))) (exists (o2 o3 o4 t y z) Appendix C. Additional CIMOSA Information 198

(and (occurrence o f o2 ( e n t e r p r i s e function t)) (occurrence o f o3 ( e n t e r p r i s e function y)) (occurrence o f o4 ( e n t e r p r i s e function z)) (precedes o1 o2) (precedes o1 o3) (precedes o1 o4) (= (beginof o2) (beginof o3)) (= (beginof o2) (beginof o4))))) )

( cl comment ”Rendez vous Rules”) ( cl −comment ”WHEN (ES(EF2)− = value 2 AND ES(EF3) = value 3 AND ES(EF4)− = value 4 ) DO EF5” ) (forall (o2 o3 o4 x y z) ( i f ( and (holds value 2 o2)(holds value 3 o3 ) ( holds value 4 o4 ) (occurrence of o2 (enterprise f u n c t i o n x )) (occurrence of o3 (enterprise f u n c t i o n y )) (occurrence of o4 (enterprise f u n c t i o n z ))) (exists (o5 t) (and (occurrence o f o5 ( e n t e r p r i s e function t)) (precedes o2 o5) (precedes o3 o5) (precedes o4 o5)))))

( cl comment ”Loop Rules”) ( cl −comment ”WHEN (ES(EF1) = loop value) DO EF1”) (forall− (o1 x) ( i f (and (holds loop v a l u e o1 ) (occurrence of o1 (enterprise function x))) (occurrence of o1 (enterprise function x))))

( cl comment ”Process Completion Rules”) ( cl −comment ”WHEN (ES(EF1) = end s t a t x AND ES(EF2) = e n d s t a t y −) DO FINISH”) ( cl comment ”use leaf node to represent the end of a process/ −occurrence tree”) Appendix C. Additional CIMOSA Information 199

( cl comment ”if EF(f) is leaf node, then it must mean EF1 and EF2− reached their specific end states o3 and o4, respectively ”...?) (forall (s a o1 o2 f) ( i f ( and ( l e a f o c c o2 o1 ) (occurrence of o2 (enterprise f u n c t i o n f ))) (exists (o3 o4 g i j) (and (precedes o3 o2)(precedes o4 o2 ) (occurrence o f o3 ( e n t e r p r i s e f u n c t i o n f ))(occurrence o f o4 ( e n t e r p r i s e f u n c t i o n g )) ( holds e n d s t a t x o3 ) ( holds e n d s t a t x o4 ) ) )))

( cl comment ”Run Time Choice Rules”) ( cl −comment ”WHEN− (ES(EF1) = end s t a t 1 ) DO S = (EF2 XOR EF3 XOR −EF4) ” ) ( cl comment ”use disjunctive clauses to model XOR”) ( cl −comment ”XOR is defined as (p xor q = (p ˆ not q) v (not p ˆ −q ) ) ” ) ( cl comment ”for simplicity’s sake, we assume there is an −alternative between TWO different enterprise functions”) (forall (o1 x) ( i f (and (holds end s t a t 1 o1 ) (occurrence of o1 (enterprise function x))) (exists (o2 o3 y) ( or ( and (and (occurrence o f o2 ( e n t e r p r i s e f u n c t i o n y ))(precedes o1 o2)) (not (and (occurrence o f o3 ( e n t e r p r i s e f u n c t i o n y ))(precedes o1 o3)))) ( and (and (occurrence o f o3 ( e n t e r p r i s e f u n c t i o n y ))(precedes o1 o3)) Appendix C. Additional CIMOSA Information 200

(not (and (occurrence o f o2 ( e n t e r p r i s e f u n c t i o n y ))(precedes o1 o2)))) ))))

( cl comment ”Unordered Set Rules”) ( cl −comment ”WHEN (ES(EF1) = end s t a t 1 ) DO S = EF2 , EF3 , EF4 ” −) { } ( cl comment ”set of execution is unknown AND all EF need to −be repeated at least once”) − − (forall (o1 x) ( i f (and (holds value o1) (occurrence of o1 (enterprise function x))) (exists (o2 o3 o4 t y z) (and (occurrence o f o2 ( e n t e r p r i s e function t)) (occurrence o f o3 ( e n t e r p r i s e function y)) (occurrence o f o4 ( e n t e r p r i s e function z)) (precedes o1 o2) (precedes o1 o3) (precedes o1 o4)))))

) Appendix D

Additional HomeServices Information

D.1 Sample Item XML Result from Amazon

B0002TXNX0 http://www.amazon.com/Black Decker 9099KC 7 2 Volt Cordless/dp /B0002TXNX0%3FSubscriptionId%3DAKIAJHNOF4OERYF3SWSQ%26tag%3− − − − − − Dserv07 20%26linkCode%3Dxm2%26camp%3D2025%26 c r e a t i v e%3 D165953%26creativeASIN%3DB0002TXNX0− Tools & Home Improvement Black & Decker 9099KC 315273 0028877326764 0028877326764 Balanced mid handle design increases the overall comfort of the drill− and the user’s control when using the d r i l l

201 Appendix D. Additional HomeServices Information 202

Fan cooled motor contributes to a longer life of the d r i l l Keyless chuck for quick and easy bit changes 2 speeds switch with forward/reverse Low f o r c o n t r o l − when screwdriving; high for drilling Includes: 7.2 Volt drill with integral battery and keyless chuck and charger− 300 910 3<−/Weight> 890 − Black & Decker 4028 USD $40.28 Black & Decker 9099KC 9099KC 300 910 305 890 − 1 9099KC Home Improvement TOOLS Black & Decker EMY 5148839 −Black & Decker 028877326764 028877326764 2 year Warranty Appendix D. Additional HomeServices Information 203

2270 USD $22.70 1969 USD $19.69 21 9 0 0 2 1 http://www.amazon.com/gp/offer l i s t i n g /B0002TXNX0%3 FSubscriptionId%3DAKIAJHNOF4OERYF3SWSQ%26tag%3Dserv07− 20%26linkCode%3Dxm2%26camp%3D2025%26 c r e a t i v e%3D386001%26 −creativeASIN%3DB0002TXNX0 New 4JTBFiR1gdxwdpzRIuosYP68Tw6jz0ds%2 F65G6plTWXSSGFyOFdNdBHZi CVWMC5qLFwwKHjpHl9g9idyEQCPz9CSGY60Xg7RS1%2 BwYCCotii6fZrRL qL98ug%3D%3D 2270 USD $22.70 1758 USD $17.58 44 Appendix D. Additional HomeServices Information 204

Usually ships in 24 hours now 0 0 1 Used S51qO27ut2KczOkvKuUcnj0RVg2GlhO1jQGkhnfy6UX0EvRdCtWV% 2Bf85SftDPZZj%2FO1AP47fxSGHXoN67%2FKnVrc2AeN9CKoW9grfJ9z 6hTtrLIevhuVh95Xb4P5BdeWOl7xbRWe0Nry%2BD3qtkJeMecZf0Yy5 Xnrx 1969 USD $19.69 2059 USD $20.59 51 Usually ships in 1 2 business days − now 24 48 0 Appendix D. Additional HomeServices Information 205

D.2 Sample Item XML Result from Sears

− SPM609745014 MKT $128.27

]]> 10153 12605 0 1 1 0 0 f a l s e f a l s e 0 1749892778 f a l s e Appendix D. Additional HomeServices Information 206

0 0 128.27 128.27 f a l s e f a l s e Lithium Ion Technology: Lighter , more compact, no memory, longer life 20V Max Lithium Ion Battery: Holds charge longer between use and has longer cycle life 11 Position Clutch: Provides precise control for drilling into wood, metal, plastic , and all screwdriving tasks Compact and Lightweight: Less fatigue and allows users to drill / screw in confined spaces Variable Speed: Allows countersinking without damaging material ]]> − 1749892778 Ship

No true Appendix D. Additional HomeServices Information 207

0 VD true f a l s e NONVARIATION f a l s e Y Y 0 The action is successful Server: PROD SERVER 404 2 Tracking ID: 1366120886491 API Client− Session− − Key:| null Time : Tue Apr 16{ 09:01:26 CDT}| 2013 UID : 5089853257140110922| From Cache : Y | |

D.3 API Queries for Product Information Retrieval

The queries performed against the Amazon API include parameters that are not listed in the left sidebar of the tool. The queries need to copied into the Unsigned URL text box as shown in Figure D.1. The respective API queries/commands for both the Amazon Web Service and cURL tools are listed under each product subsection and the XML output can be found in the appendices. Appendix D. Additional HomeServices Information 208

Figure D.1: Amazon API queries need to be copied into the Unsigned URL text box.

Black & Decker LDX112C 12-Volt MAX Lithium-Ion Drill/-

Driver

This drill is offered by both companies on the following web pages: Amazon: http://www.amazon.com/dp/B004443WVW/ • http://webservices .amazon.com/onca/xml?Service= AWSECommerceService&Operation=ItemLookup&SubscriptionId= AKIAJHNOF4OERYF3SWSQ&AssociateTag=serv07 20&Version =2011 08 01&ItemId=B004443WVW&IdType=ASIN&Condition=New&− ResponseGroup=Images− − ,ItemAttributes , Offers , Accessories , AlternateVersions ,BrowseNodes,EditorialReview ,OfferFull , OfferSummary,Reviews ,SalesRank , Similarities ,Tracks , VariationImages , VariationMatrix ,VariationSummary , V a r i a t i o n s

Sears: • http://www.sears.com/black-decker-12-v-max-lithium-drill-driver/ p-00930268000P curl ”http://api.developer.sears.com/v1/productdetails? apikey=0ea2982977bb5217b3973bd2c315be39&store=Sears& showSpec=yes&textOnly=yes&partNumber=00930268000P”

Tajima Tool Corp - Rapid Pull 265 15 TPI blade

This blade is offered by both companies on the following web pages: Appendix D. Additional HomeServices Information 209

Amazon: http://www.amazon.com/dp/B0008IVWVU • http://webservices .amazon.com/onca/xml?Service= AWSECommerceService&Operation=ItemLookup&SubscriptionId= AKIAJHNOF4OERYF3SWSQ&AssociateTag=serv07 20&Version =2011 08 01&ItemId=B0008IVWVU&IdType=ASIN&Condition=New&− ResponseGroup=Images− − ,ItemAttributes , Offers , Accessories , AlternateVersions ,BrowseNodes,EditorialReview ,OfferFull , OfferSummary,Reviews ,SalesRank , Similarities ,Tracks , VariationImages , VariationMatrix ,VariationSummary , V a r i a t i o n s

Sears: • http://www.sears.com/tajima-tool-corp-rapid-pull-265-15-tpi/ p-00988400000P curl ”http://api.developer.sears.com/v1/productdetails? apikey=0ea2982977bb5217b3973bd2c315be39&store=Sears& showSpec=yes&textOnly=yes&partNumber=00988400000P”

Craftsman 16 oz. Rubber Mallet

This mallet is offered by both companies on the following web pages:

Amazon: http://www.amazon.com/dp/B001O8QSTY • http://webservices .amazon.com/onca/xml?Service= AWSECommerceService&Operation=ItemLookup&SubscriptionId= AKIAJHNOF4OERYF3SWSQ&AssociateTag=serv07 20&Version =2011 08 01&ItemId=B001O8QSTY&IdType=ASIN&Condition=New&− ResponseGroup=Images− − ,ItemAttributes , Offers , Accessories , AlternateVersions ,BrowseNodes,EditorialReview ,OfferFull , OfferSummary,Reviews ,SalesRank , Similarities ,Tracks , VariationImages , VariationMatrix ,VariationSummary , V a r i a t i o n s

Sears: • http://www.sears.com/craftsman-16-oz-rubber-mallet/p-00945787000P

curl ”http://api.developer.sears.com/v1/productdetails? apikey=0ea2982977bb5217b3973bd2c315be39&store=Sears& showSpec=yes&textOnly=yes&partNumber=00945787000P” Appendix D. Additional HomeServices Information 210

Delta Faucet U4993-SS Universal Showering Components Shower

Arm and Flange, Stainless

This faucet flange is offered by both companies on the following web pages: Amazon: http://www.amazon.com/dp/B006WKZVM4 • http://webservices .amazon.com/onca/xml?Service= AWSECommerceService&Operation=ItemLookup&SubscriptionId= AKIAJHNOF4OERYF3SWSQ&AssociateTag=serv07 20&Version =2011 08 01&ItemId=B006WKZVM4&IdType=ASIN&Condition=New&− ResponseGroup=Images− − ,ItemAttributes , Offers , Accessories , AlternateVersions ,BrowseNodes,EditorialReview ,OfferFull , OfferSummary,Reviews ,SalesRank , Similarities ,Tracks , VariationImages , VariationMatrix ,VariationSummary , V a r i a t i o n s

Sears: • http://www.sears.com/delta-shower-arm-and-flange/p-08319019000P

curl ”http://api.developer.sears.com/v1/productdetails? apikey=0ea2982977bb5217b3973bd2c315be39&store=Sears& showSpec=yes&textOnly=yes&partNumber=08319019000P”

KNIPEX 95 12 200 Comfort Grip Cable Shears

This faucet flange is offered by both companies on the following web pages: Amazon: http://www.amazon.com/dp/B000I1L6QI • http://webservices .amazon.com/onca/xml?Service= AWSECommerceService&Operation=ItemLookup&SubscriptionId= AKIAJHNOF4OERYF3SWSQ&AssociateTag=serv07 20&Version =2011 08 01&ItemId=B000I1L6QI&IdType=ASIN&Condition=New&− ResponseGroup=Images− − ,ItemAttributes , Offers , Accessories , AlternateVersions ,BrowseNodes,EditorialReview ,OfferFull , OfferSummary,Reviews ,SalesRank , Similarities ,Tracks , VariationImages , VariationMatrix ,VariationSummary , V a r i a t i o n s

Sears: • http://www.sears.com/knipex-8inch-cable-shears-comfort-grip/ p-00990571000P Appendix D. Additional HomeServices Information 211

curl ”http://api.developer.sears.com/v1/productdetails? apikey=0ea2982977bb5217b3973bd2c315be39&store=Sears& showSpec=yes&textOnly=yes&partNumber=00990571000P”

D.4 Transforming Raw Vendor Product Data

This section discusses how to transform the raw product data into RDF/XML format.

D.4.1 Using GRDDL to Transform XHTML/XML into RDF

The simplest method for transforming XHMTL documents into RDF is embed a reference of transformations using the element found in the head of the document (see below from an example from [33]). Within XHTML pages, microformats are used to embed semantic markup for a specific domain in human-readable documents [33]. Robin’s Schedule − − ...

Similarly, to apply GRDDL to a XML document, one needs to add the grddl namespace declaration and a grddl:transformation attribute that contains an internationalized resource identifier (IRI) to the root element of the document. The example below is taken from [11]; the XML document is linked to two GRDDL trans- formations, http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl and http://www.w3.org/2001/sw/grddl-wg/td/glean_title.xsl. Appendix D. Additional HomeServices Information 212

Are You Experienced? [...]

D.4.2 Using xsltproc

In order to transform the XML into RDF, we utilize the xsltproc tool that is included in the XSLT C library for the GNOME desktop environment. We utilize the Windows binaries of this tool that are included in the libxml XML processor. To use xsltproc, we copy over the binary files into one folder (e.g., C: libxslt bin ). \ \ \ For simplicity’s sake, it is best to keep the stylesheet and raw XML files in the same folder as the binary files. In Microsoft Windows’ Command Prompt, we enter the following commands to con- vert the raw XML file into the RDF by applying the XSLT spreadsheet to the processor: xsltproc.exe xml2rdf3 sears.xsl shears s e a r s . xml > s h e a r s s e a r s . r d f xsltproc.exe xml2rdf3 sears.xsl shears amazon . xml > shears amazon . r d f

The first argument is the xsltproc program, the second is file name of the stylesheet to be applied, then the raw XML file and the file name of the resultant RDF file. The resultant RDF files are found in the same folder as the raw XML and XSLT files.

D.5 Using AllegroGraph to Test Product Mappings

This section outlines how to load and test the ontology mappings in AllegroGraph. Appendix D. Additional HomeServices Information 213

D.5.1 Importing the Data into AllegroGraph

For this project, we use the AllegoGraph RDFStore provided by Hunch Manifest, Inc. to test the preliminary mappings that are listed in Sections 6.3.4 and 6.3.5. All of the product data is imported into the STLBack data store on the AllegroGraph server. Note that we had to manually enter in the required namespaces into AllegroGraph (the URIs are subject to change): amazon: http://www.example.org/schemas/amazon# • gist: http://ontologies.semanticarts.com/gist# • hso: http://www.example.org/schemas/hso# • sears: http://www.example.org/schemas/sears# •

D.5.2 Using AllegroGraph’s Materializer and Reasoner

Since AllegroGraph stores the product information in triple form, the preliminary map- pings were rewritten in SPARQL and are discussed in the subsequent section. Before we can carry out the SPARQL queries in AllegroGraph, the following steps must be followed: 1. Load in triples and owl:equivalentProperty mappings into the STLBack data store by uploading the following files: RDF triples: • – bd drill amazon.rdf – mallet sears.rdf – bd drill sears.rdf – sawblade amazon.rdf – flange amazon.rdf – sawblade sears.rdf – flange sears.rdf – shears amazon.rdf – mallet amazon.rdf – shears sears.rdf

RDF/OWL Mappings in Turtle form: • – mappings.nt 2. Define the required namespaces (such as amazon, hso, sears) in the Namespaces tab. 3. In the repository Overview screen, materialize the triples by clicking on Materialize Entailed Triples and select all rules offered, as shown in Figure D.2. 4. Enable ‘Reasoning’ while running the queries, as shown in Figure D.3. Appendix D. Additional HomeServices Information 214

Figure D.2: Selecting rules for AllegroGraph’s materializer.

Figure D.3: Enabling reasoning in the SPARQL query.

D.6 Results from SPARQL Queries for HSO Map-

pings

The following section outlines the results from the SPARQL queries used to test the ontology mappings. These results are summarized as follows: Table D.1 lists the cheapest products offered by Sears and Amazon. • Table D.2 lists the cheapest products offered by Sears and Amazon based on a • keyword.

Table D.3 lists the average price of products (specified by keyword) offered by Sears • and Amazon.

Table D.4 lists the average price of all products offered by Sears and Amazon. • Table D.5 lists the average price of products offered by Sears and Amazon based • on a keyword.

Table D.6 lists the combined product attributes of a product offered by both ven- • dors.

Table D.7 lists product data from the vendors, combined with information from • DBPedia. Appendix D. Additional HomeServices Information 215

Table D.1: Results of finding the cheapest price of products.

mfgno minprice ”95 12 200” ”65.99” ”GNB-265” ”10.99” ”45787” ”10.99” ”U4993-SS” ”43.38” ”LDX112C” ”49.99”

Table D.2: Results of finding the cheapest price of products based on keyword.

mfgno minprice prodTitle ”LDX112C” ”49.99” ”12 V Max Lithium Drill/Driver ”

Table D.3: Results of finding the average price of products based on keyword.

searsTitle amazonTitle searsavg amazonavg ”12 V Max ”Black & Decker ”49.99” ”59.99” Lithium Drill/- LDX112C 12-Volt Driver ” Max Lithium-Ion r n Drill/Driver” \ \

Table D.4: Results of finding the average price of products and lists them according to manufacturer number.

mfgno searsavg amazonavg ”U4993-SS” ”43.38” ”55.4” ”GNB-265” ”1.099” ”1.099” ”LDX112C” ”49.99” ”59.99”

Table D.5: Results of finding the average price of products based on keyword for both vendors and lists them according to manufacturer number.

mfgno searsavg amazonavg ”LDX112C” ”49.99” ”59.99” Appendix D. Additional HomeServices Information 216

Table D.6: Results of finding the combined product model, sorted by manufacturer part number. (Results are truncated due to limited page space.) mfgno amazonTitle amazondescription searsTitle searsdescription searsdescription2 ”GNB- ”Tajima ”Fine cut ”Rapid :b7D9DF37Dx2199 ”15 TPI Fine- 265” GNB-265 3-times Pull 265 Cut blade, 1 15 TPI faster 15 TPI blade pack” Rapid Pull than nor- blade ” Replace- mal r n ment r n blades”\ \ Blade”\ \ ”LDX112C””Black & ”Compact ”12 V Max ”Black & Decker and Lithium Decker 12 V LDX112C lightweight Drill/- max lithium 12-Volt for less Driver drill/driver. Max user fa- ” Drilling through Lithium- tigue wood, metal, Ion r n and r n and plastic. By Drill/-\ \ for\ drilling\ providing extra Driver” and screw- level of control, driving in the 11 position confined clutch prevents spaces” stripping and overdriving screws. ”U4993- ”Delta ”See what ”Shower :b7D9DF37Dx1908 ”Timeless SS” Faucet Delta can Arm And design for to- U4993-SS do” Flange ” day&#039;s Universal homes” Showering Compo- nents r n Shower\ \ Arm and Flange, Stainless” Appendix D. Additional HomeServices Information 217

Table D.7: Results of the federated query. Note that the results are incorrect and that the brandDBPediaURI field is empty. productBrand foundingYear searstitle amazontitle brandDBPediaURI ”Craftsman” ”2003” ”16 oz. Rubber ”Craftsman 16 Mallet” oz. Rubber Mallet” ”Knipex” ”2003” ”8&#034; ”KNIPEX 95 Cable shears- 12 200 Comfort comfort grip ” Grip Cable Shears” ”Craftsman” ”2002” ”16 oz. Rubber ”Craftsman 16 Mallet” oz. Rubber Mallet” ”Knipex” ”2002” ”8&#034; ”KNIPEX 95 Cable shears- 12 200 Comfort comfort grip ” Grip Cable Shears” ”Craftsman” ”2001” ”16 oz. Rubber ”Craftsman 16 Mallet” oz. Rubber Mallet” ”Knipex” ”2001” ”8&#034; ”KNIPEX 95 Cable shears- 12 200 Comfort comfort grip ” Grip Cable Shears” ”Craftsman” ”2000” ”16 oz. Rubber ”Craftsman 16 Mallet” oz. Rubber Mallet” ”Knipex” ”2000” ”8&#034; ”KNIPEX 95 Cable shears- 12 200 Comfort comfort grip ” Grip Cable Shears” ”Craftsman” ”1999” ”16 oz. Rubber ”Craftsman 16 Mallet” oz. Rubber Mallet” ”Knipex” ”1999” ”8&#034; ”KNIPEX 95 Cable shears- 12 200 Comfort comfort grip ” Grip Cable Shears” ”Craftsman” ”1998” ”16 oz. Rubber ”Craftsman 16 Mallet” oz. Rubber Mallet” ”Knipex” ”1998” ”8&#034; ”KNIPEX 95 Cable shears- 12 200 Comfort comfort grip ” Grip Cable Shears” Appendix D. Additional HomeServices Information 218

D.7 Sample GoodRelations Tags in Sears Product

Pages

A snippet of the GoodRelations tags used in a Sears product page is shown in the sample HTML source below: