by Carmen Chui - University of Toronto T-Space · chitecture (CIMOSA) framework by augmenting its constructs with terminology found in PSL. Finally, we attempt to map two semantically-weak

Axiomatized Relationships Between Ontologies

by

Carmen Chui

A thesis submitted in conformity with the requirementsfor the degree of Master of Applied Science

Graduate Department of Mechanical & Industrial EngineeringUniversity 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 Gruninger 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 Gruninger. 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 Introduction 1

1.1 Ontologies & the Semantic Web . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 The Big Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Background 8

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.


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.


• 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


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


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 ofthe strong DOLCE ontology.

2. Ontology Composition: the combination of strong theories pertaining to geometry,mereology, and time found in COLORE outlines the relationships between thestrong 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 theweak 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-


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 Chapter 2, we discuss the motivations for this re-

search opportunity, describe the background theories used, and outline the methodologies

taken; in Chapter 3, we outline the techniques used to decompose DOLCE into modules

and discuss our findings; in Chapter 4, we outline our approach to mapping DOLCE

with theories found in COLORE and discuss our findings; in Chapter 5, we describe the

process ontology developed for CIMOSA and its potential applications within the com-

munity; in Chapter 6, we discuss the techniques used to map web services together with

the use of ontologies and their applications in e-commerce; and finally, in Chapter 7, 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 Chapter 3, 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.

http://www.loa.istc.cnr.it/ontologies/DLP_397.owl

http://www.loa.istc.cnr.it/ontologies/DLP_397.owl


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.

http://code.google.com/p/colore/


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 L(T ), is the set of first-order

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 σ ∈ L(T1),

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

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

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 6|= σ and T2 |= σ.

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 |= σ


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 = 〈H,≤〉 is a partially ordered, finite set of theories

H = T1, . . . , Tn, such that:

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.


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 L(T1), such that

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

T2 |= (∃v1)π∀

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

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

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

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

“T1 is interpretable in T2.”


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 σ ∈ L(T1),

T1 6|= σ ⇒ T2 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].


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 6= j. A theory T is reducible to T1, ..., Tn iff T is definably equivalent to

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


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/.

http://www.cs.unm.edu/~mccune/mace4/


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 characterizesthe semantics of an ontology’s terminology.


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 androbust enough to represent the necessary process information for any givenapplication” [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 that5http://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.

http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_core/psl_core.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_core/psl_core.clif


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 classeswithin the PSL ontology.

• Time: each activity occurrence is associated with unique timepoints that markthe 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 capturedin 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 behaviourin the world to allow software systems to make predictions about the future andexplanations with the past. PSL-Core captures basic intuitions about state and itsrelationship to activities with fluents which are properties in the domain that canchange. A fluent is changed by the occurrence of activities, and a fluent can onlybe 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.


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 theseparticulars, 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.

http://wonderweb.semanticweb.org/deliverables/D17.shtml

http://wonderweb.semanticweb.org/deliverables/D17.shtml


Figure 2.1: Classification of DOLCE categories from [51].


Table 2.1: Basic Categories in DOLCE.

Abbreviation Category

AB AbstractACC AccomplishmentACH AchievementAPO Agentive Physical ObjectAQ Abstract QualityAR Abstract RegionAS Arbitrary Sum

ASO Agentive Social ObjectED EndurantEV EventF FeatureM Amount of Matter

MOB Mental ObjectNAPO Non-agentive Physical ObjectNASO Non-agentive Social ObjectNPED Non-physical EndurantNPOB Non-physical Object

PD Perdurant, OccurrencePED Physical EndurantPOB Physical ObjectPQ Physical QualityPR Physical Region

PRO ProcessPT ParticularQ QualityR RegionS Space Region

SAG Social AgentSC SocietySL Spatial Location

SOB Social ObjectST State

STV StativeT Time Interval

TL Temporal LocationTQ Temporal QualityTR Temporal Region


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) andDif(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.

http://www.cs.unm.edu/~mccune/mace4/

http://aaai11dolce.tripod.com/dolce-s-specification-in-many-sorted-first-order-logic.html

http://aaai11dolce.tripod.com/dolce-s-specification-in-many-sorted-first-order-logic.html


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)


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 PRE(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

axiomMSD(TQ, PD) (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(TQ, PD) ≡ SD(TQ, PD) ∧ SD(PD, TQ).


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.


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

Being Present“x is present at t”

PRE(x, t)

Constitution“x constitutes y during t”

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

Parthood“x is part of y”

P (x, y) ⊃ (AB(x) ∨ PD(x)) ∧ (AB(y) ∨ PD(y))

Participation“x participates in y during t”

PC(x, y, t) ⊃ (ED(x) ∧ PD(y) ∧ T (t))

Temporary Parthood“x is part of y during t”

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


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 itslife. For example, material objects are mereologically variable because they canlose or gain parts.

2. An endurant is mereologically invariant iff they remain the same across all possibleworlds. For example, amounts of matter are mereologically invariant since all oftheir 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


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 Chapter 4. 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-


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

http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/index_e.htm

http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/index_e.htm

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

http://aaai11dolce.tripod.com/architectural-specification.html


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

http://colore.googlecode.com/svn/trunk/ontologies/dolce/dolce.tptp


Figure 3.1: Structure of DOLCE’s subtheories in [48].


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.

4Denoted as Tdolce dependence, Tdolce participation, and Tdolce temporary parthood, respectively.


DOLCE Hierarchy

dolce constitution

dolce temporary parthood dolce participation

dolce taxonomy

dolce time mereology

dolce presentdolce dependence

dolce mereology

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


dolce present∪ dolce time mereology

cem mereology

ideal cem wmg

∪ ideal cem wmg∪ ideal cem downward m foliation

ideal cem lower reflect down foliation

∪ dolce present∪ dolce time mereology

∪ dolce temporary parthooddolce constitution

∪ dolce present∪ dolce time mereology

dolce temporary parthood

∪ ideal cem wmgideal cem downward m foliation

Figure 3.3: Mappings between DOLCE and COLORE theories. Solid arrows denoteconservative extensions and solid lines indicate equivalence.


Mereological Geometries, Bundles & Foliations

In our reduction, we utilized structures from the mereological geometry, mereological

bundle, and mereological foliations hierarchies:

• A mereological geometry5 is the amalgamation of a bipartite incidence structureand a mereology that is specified on sets of collinear points (the points that areall incident with the same line). Sets of collinear points need to satisfy axiomsfor 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 frommereology by introducing a ternary relation tpart(x, y, t) that specifies a relativizedparthood 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 witha point; a mereology is not specified on sets of intersecting lines due to the notionof temporary parthood. In the philosophical literature, the relation for temporaryparthood is not considered to be antisymmetric, in contrast to the parthood rela-tion in a mereology. Due to this, mereological bundles contain quasiorderings onsets of intersecting lines.

• Mereological foliations7 are simply an amalgamation of mereological geometriesand mereological bundles. A mereology is specified on each set of collinear pointsand mereological bundle is specified on each set of intersecting lines. Figure 3.4depicts a structureM∈Mm foliation. Figure 3.4(a) shows the mereology within themereological geometry, and Figure 3.4(b) shows the incidence structure. Note thatthis is the same incidence structure as the one in the mereological bundle. Figure3.4(c) shows the mereological bundle: in particular, the quasiorder that is specifiedon 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 planesand 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

http://code.google.com/p/colore/source/browse/trunk/ontologies/mereological_geometry/

http://code.google.com/p/colore/source/browse/trunk/ontologies/mereological_geometry/

http://code.google.com/p/colore/source/browse/trunk/ontologies/mereological_bundle/

http://code.google.com/p/colore/source/browse/trunk/ontologies/mereological_bundle/

http://code.google.com/p/colore/source/browse/trunk/ontologies/mereological_foliation/

http://code.google.com/p/colore/source/browse/trunk/ontologies/mereological_foliation/

http://code.google.com/p/colore/source/browse/trunk/ontologies/incidence_bundle

http://code.google.com/p/colore/source/browse/trunk/ontologies/incidence_bundle


l1

l2

t1

t2 t3

t4

t5 t6

(a) (b)

l1 l2 l3

t1 t3t2 t4 t5 t6

l2

l3

l2

l3

l1

l1 l3

(c)

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

• An incidence foliation9 is an amalgamation of a mereological geometry and anincidence bundle: a mereology is specified on each set of collinear points and anincidence 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

3.5 form the basis for Hsubposet. 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

http://code.google.com/p/colore/source/browse/trunk/ontologies/incidence_foliation

http://code.google.com/p/colore/source/browse/trunk/ontologies/incidence_foliation

http://code.google.com/p/colore/source/browse/trunk/ontologies/subposet


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 relationtpart(x, y, z) that specifies a relativized parthood relation on sets of lines that arecoincident 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) thatspecifies a relativized ordering relation on sets of lines that are coincident with thesame point.

• Subposet foliations12 are an amalgamation of mereological geometries and subposetbundles.

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

http://code.google.com/p/colore/source/browse/trunk/ontologies/subposet_bundle

http://code.google.com/p/colore/source/browse/trunk/ontologies/subposet_bundle

http://code.google.com/p/colore/source/browse/trunk/ontologies/subposet_foliation

http://code.google.com/p/colore/source/browse/trunk/ontologies/subposet_foliation

http://code.google.com/p/colore/source/browse/trunk/ontologies/mereological_geometry/ideal_cem_wmg.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/mereological_geometry/ideal_cem_wmg.clif


subposet

upper_set lower_set

filter ideal

subposet_root

upper_preservelower_preservelower_reverse upper_reverse

partial_orderingmereology

chain_antichain

Figure 3.5: Ontologies in Hsubposet: the hierarchy of theories of relationships betweenpartially ordered sets. Solid arrows denote conservative extensions and dashed arrowsdenote non-conservative extensions.


m_mereology

cm_mereology

ppp_m_mereology

ppp_mm_mereology

mm_mereology

dense_mereology

tree_mereology

discrete_mereology

em_mereology

ex_mm_mereology

cem_mereology

mem_mereology

cem_Gcem_C cem_notG cem_notC

ex_m_mereology

sum_mereologyprod_mereology

ex_cm_mereology

dense_mm_mereology

tree_mm_mereology

inclusion_space

Figure 3.6: Ontologies in Hmereology. Solid arrows denote conservative extensions anddashed arrows denote non-conservative extensions.


transitivity

quasi-order

partial_order

linear_order

semilinear_order

tree

forest

semiorder

interval_order

weak_order

series_parallel

semilattice

lattice

total_preorder

densitydiscreteness min_existsmax_exists

discretesemilinear_order

discretelinear_order

denselinear_order

discretepartial_order

discretelinear_order

no_enddense

linear_orderno_end

bounded denselinear_order

bounded discretelinear_order

discrete_chains

discrete_forest

partialsemiorder

boundedlinear_order

densepartial_order

densesemilinear_order

initial_discretelinear_order

final_discretelinear_order initial_dense

linear_orderfinal_denselinear_order

chains

denseweak_separative

Figure 3.7: Ontologies in Hordering. Solid arrows denote conservative extensions anddashed arrows denote non-conservative extensions.


• ideal: collinear points form an ideal14 in the global cem mereology

• cem: ‘cem’ refers to cem mereology, which is the global mereology on all pointsin 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 time mereology

• Tdolce mereology

• Tdolce present

• Tdolce temporary parthood

• 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 wmg

∪ ∪

∪ ∪

∪

Physical EndurantPED(x)


ideal cem downward m foliation

Non-Physical EndurantNPED(x)


ideal cem downward m foliation ∪ ∪ ∪

ideal cem wmg

ideal cem wmg

ideal cem downward foliation

ideal cem wmg

ideal cem wmg

ideal cem wmg

QualitiesQ(x)

EndurantsED(x)

≡ dolce constitution

≡ dolce temporary parthood

≡ dolce present

PerdurantsPD(x)

Figure 3.8: Relationships between DOLCE modules with mathematical structures inCOLORE.

14An ideal is a set closed under the P (x, y) and sum(x, y, z) relations. For any two points, its sum isalso in the set.


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 = {PT,AB,R, TR, T, PR, S,AR,Q, TQ, TL, PQ, SL,AQ,

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

SAG, SC,NASO,AS, PD,EV,ACH,ACC, STV, ST, PRO}

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,


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

http://colore.googlecode.com/svn/trunk/ontologies/dolce_taxonomy/dolce_taxonomy.clif

http://colore.googlecode.com/svn/trunk/ontologies/dolce_taxonomy/dolce_taxonomy.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_time_mereology/dolce_time_mereology.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_time_mereology/dolce_time_mereology.clif


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

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

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

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

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

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

∀x NPOB(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 TL(x)) ⊃ TQ(x) (3.2.10)

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

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

∀x (APO(x) ∨NAPO(x)) ⊃ POB(x) (3.2.13)

∀xMOB(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.


∀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.


∀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)) ≡ ((APO(x) ∨NAPO(x)) (3.2.41)

∀x (APO(x)) ⊃ ¬NAPO(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.


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/

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_time_mereology/interprets/output/

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_time_mereology/interprets/output/


(∀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.


3.4 DOLCE’s Mereology (Tdolce mereology)

Recall from Chapter 2 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

of the axioms found in Tdolce mereology; as well, the axioms can be found in COLORE18.

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

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_mereology/dolce_mereology.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_mereology/dolce_mereology.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_taxonomy/taxonomy.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_taxonomy/taxonomy.clif


(∀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)


(∀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.

ED(x) PD(x) Q(x)

PT \AB(x)

PED(x) NPED(x)

DOLCE Categories

(a) A taxonomy of DOLCE categories.

L1 L2 L3

L

L4 L5

(b) A taxonomy of lines.

Figure 3.15: Corresponding taxonomies of DOLCE categories and lines.


(∀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,


(∀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

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_present/dolce_present.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_present/dolce_present.clif


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

(∀x) L4(x) ≡ PED(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.


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/

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_present/interprets/output/

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_present/interprets/output/


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 tPP (x, y, t). Figure 3.18 lists all of the axioms found in

Tdolce temporary parthood; as well, the axioms can be found in COLORE23.

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) andP (x, y, t) in an input file will return an error because the theorem prover is unable to discern whetherthese 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

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_temporary_parthood/dolce_temporary_parthood.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_temporary_parthood/dolce_temporary_parthood.clif


(∀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) (tPP (v, z, t) ≡ (tPP (v, x, t) ∧ tPP (v, y, t))) (3.7.11)

Figure 3.18: Axioms of Tdolce temporary parthood.


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-

joint constructs24, 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)


24Recall Axioms 3.2.23 to 3.2.25 in Tdolce taxonomy.


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

�



(∀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) 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)


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

�


(∀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) L1(x) ≡ ED(x)

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

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

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


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

�


(∀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) ED(x) ≡ line1(x) ∨ line2(x)

(∀x) PD(x) ≡ line3(x) ∧ L2(x)

(∀x)Q(x) ≡ line3(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 1ideal cem downward m foliation ∪ T 2


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


�

Theorem 3.7.5 Tdolce temporary parthood is definably equivalent to

T 1ideal cem downward m foliation ∪ T 2


∪T 3ideal cem wmg ∪ Ttaxonomy


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

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_temporary_parthood/interprets/output/

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_temporary_parthood/interprets/output/

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_constitution/dolce_constitution.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_constitution/dolce_constitution.clif


(∀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


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

are disjoint constructs27, 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).



(∀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) 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 6= y) ∧ PED(x) ∧ PED(y) ∧ T (z)

(∀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)

27Recall Axioms 3.2.23 to 3.2.25 in Tdolce taxonomy).


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


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

�



(∀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) 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)


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

�


(∀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)




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

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

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

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


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

�



(∀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) 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 6= y) ∧NPED(x) ∧NPED(y) ∧ T (z)

(∀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)



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

�


(∀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) 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)


T 1ideal cem lower reflect down foliation ∪ T 4


∪T 2ideal cem downward m foliation ∪ T 3

ideal cem wmg ∪ Ttaxonomy ∪ Π |= Tdolce constitution

�

Theorem 3.8.6 Tdolce constitution is definably equivalent to

T 1ideal cem lower reflect down foliation ∪ T 2


∪T 3ideal cem wmg ∪ T 4



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 axiomsinvolved endurants or perdurants while preserving the taxonomic structure foundin the original DOLCE axioms.

28http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_constitution/interprets/output/

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_constitution/interprets/output/

http://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 Chapter 2, 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 containsapproximately 239,000 terms [18], whereas BFO is smaller in size [58].

2SUMO, OpenCyc, and BFO are axiomatized in SUO-KIF, Lisp, and OWL, respectively.


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 PD(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


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.

dolce present

dolce mereology

dolce participation

interval with endpoints

DOLCE Hierarchies

Combined Time Hierarchy

dolce temporary parthood


dolce constitution

dolce taxonomy

dolce dependence

periods root

Periods Hierarchy

lp infinite end

Timepoints Hierarchy

periods

finite periods

cem periods

lp ordering

linear point

sim vc end

endpoints

psl coremandatory

PSL Hierarchy

psl core root

finite sim vc end

interval mandatory

interval psl core

Interval PSL Hierarchy

Figure 4.1: Relationships between DOLCE modules and theories in COLORE. Solid linesindicate conservative extensions, dashed lines indicate non-conservative extensions, andthe 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


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.

The linear point theory, Tlinear point4, 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.

The linear timepoints with endpoints at infinity theory, Tlp infinite end5, 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 befound 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

http://code.google.com/p/colore/source/browse/trunk/ontologies/timepoints/linear_point.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/timepoints/linear_point.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/timepoints/lp_infinite_end.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/timepoints/lp_infinite_end.clif


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/

http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_time/

http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_time/


finite_sim_vc_end

finite_vc

finite_endpoints

finite_backwards

finite_no_backwa

rds

finite_no_mom

ent

finite_m

oment

finite_m

o_endpoints

finite_m

o_continuum

interval_w

ith_endpoints

mom

ent_with_endpoints

sim_vc_end

endpoints

mo_endpoints

mo_continuum

vectorcontinuum

lp_ordering

linear_point lp_infinite_end

backwa

rds

no_backwards

no_m

oment

mom

ent

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.


The theory of endpoints, Tendpoints7, 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.

The vector continuum theory, Tvector continuum8, 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.

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

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 L. The similarity of T1

and T2 is the strongest subtheory of T1 and T2, so that for all σ, φ ∈ L if T1 |= σ and

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

http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_time/endpoints.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_time/endpoints.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_time/vector_continuum.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_time/vector_continuum.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_time/sim_vc_end.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_time/sim_vc_end.clif


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

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

endpoints at infinity10, 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

Tpsl core compatible with time intervals. In Hcombined time, 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

Tfinite sim vc end from Hcombined time and Tlp infinite end from Htimepoints. The primary dif-

ference between the Tfinite sim vc end and Tsim vc end theories within Hcombined time 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

http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_time/interval_with_endpoints.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/combined_time/interval_with_endpoints.clif


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

utilize timepoints but time intervals in its time mereology, an extension of Tpsl core13 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.13We could not modify the axioms found in Tpsl core since the axioms are standardized in ISO 18629-

11:2005.


(∀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.

psl coremandatory

PSL Hierarchy

psl core root

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

14http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_core/mandatory.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_core/mandatory.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_core/mandatory.clif


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

hierarchy, Hinterval psl, 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

http://code.google.com/p/colore/source/browse/trunk/ontologies/interval_psl

http://code.google.com/p/colore/source/browse/trunk/ontologies/interval_psl


(∀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.

x

y

i1

i2

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 timeintervals may overlay one another.


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

assigns time intervals18 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

18Recall that we did not commit to a particular temporal construct in Tmandatory.

http://code.google.com/p/colore/source/browse/trunk/ontologies/interval_psl/interval_mandatory.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/interval_psl/interval_mandatory.clif


interval with endpoints

Combined Time Hierarchy

psl coremandatory

PSL Hierarchy

psl core root

finite sim vc end

interval mandatory

interval psl core


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.


pendix B.2.1 and in COLORE19. 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

the Tinterval mandatory and Tinterval psl core theories in Hinterval psl, 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.

dolce present*

dolce participation

DOLCE Hierarchy


dolce taxonomy

∆1

∆2

dolce present

interval mandatory

interval psl core


Figure 4.8: Interpretations between DOLCE modules and theories in COLORE. Solidlines 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 Tinterval psl core and Tdolce 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

http://code.google.com/p/colore/source/browse/trunk/ontologies/dolce_present/dolce_present_star.clif



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 coreand 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


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.

x

y

i1

i2

z

z

maximal sum of intervals

minimal 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))∧


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/output21Recall that our verification of DOLCE is a partial modularization of the ontology. The modules

of our verification were presented in Chapter 3, but we did not include Tdolce participation, so it will beverified in future work.

http://code.google.com/p/colore/source/browse/svn/trunk/ontologies/dolce_present/interprets/output

http://code.google.com/p/colore/source/browse/svn/trunk/ontologies/dolce_present/interprets/output


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

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

http://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


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.


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


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 buildingblocks 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 representingdifferent 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’).


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


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 thefunctionality 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 andauthorisation (Organization Elements) for functionalities, information, resourcesand 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.


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 activitiesare 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 isknown.

• 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].

b e h a v i o u r a l r u l e s e t : := <s t a r t i n g r u l e s > <b e h a v i o u r a l r u l e s><s t a r t i n g r u l e s > : := <s i m p l e s t a r t i n g r u l e> <e v e n t d r i v e n r u l e s><s i m p l e s t a r t i n g r u l e> : := WHEN (START) DO <act ion><e v e n t d r i v e n r u l e s> : := <e v e n t d r i v e n r u l e> <e v e n t d r i v e n r u l e>

<n e x t e v e n t d r i v e n r u l e s><n e x t e v e n t d r i v e n r u l e s> : := <e v e n t d r i v e n r u l e s> n i l


<e v e n t d r i v e n r u l e> : := WHEN ( <event cond i t i on> ) DO <act ion><event cond i t i on> : := START WITH <e v e n t l i s t ><e v e n t l i s t > : := event−id <next event><next event> : := AND event−id <next event> n i l<b e h a v i o u r a l r u l e s> : := <behav i ou ra l ru l e> <

n e x t b e h a v i o u r a l r u l e s><n e x t b e h a v i o u r a l r u l e s> : := <b e h a v i o u r a l r u l e s> n i l<behav i ou ra l ru l e> : := WHEN ( <t r i g g e r i n g c o n d i t i o n s> ) DO <

act ion><t r i g g e r i n g c o n d i t i o n s> : := <t r i g g e r i n g c o n d i t i o n> <

n e x t t r i g g e r i n g c o n d i t i o n><n e x t t r i g g e r i n g c o n d i t i o n> : := AND <t r i g g e r i n g c o n d i t i o n> <

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 e x t t r i g g e r i n g c o n d i t i o n> n i l<t r i g g e r i n g c o n d i t i o n> : := ES ( p ro c e s s s t ep−id ) = <Esvalue><Esvalue> : := ending−s tatus−id ANY<act ion> : := process−step−id <asynchronous spawning> <

synchronous spawning> FINISH<asynchronous spawning> : := process−step−id <o the r s t ep s><o the r s t ep s> : := & process−step−id <o the r s t ep s> n i l<synchronous spawning> : := SYNC ( <asynchronous spawning> )

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.


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

Type Syntax

Process Triggering RulesWHEN (START WITH event 1)DO EF1

Forced Sequential Rules WHEN (ES(EF1)=any) DO EF2Sequential Rules WHEN (ES(EF1)=end stat 1) DO EF1

Conditional Sequential RulesWHEN (ES(EF1)=end stat 1) DO EF2WHEN (ES(EF2)=end stat 2) DO EF3WHEN (ES(EF3)=end stat 3) DO EF4

Spawning RulesWHEN (ES(EF1)=value 1)DO EF1 & EF2 & EF3

Rendezvous Rules (Logical AND)WHEN (ES(EF1)=value 1 AND ES(EF2)=value 2 AND ES(EF3)=value 3)DO EF4

Convergence Rules (Logical OR)WHEN (ES(EF1) = value 1 OR ES(EF2) =value 2 OR ES(EF3)=value 3)DO EF4

Loop Rules WHEN ES(EF1)=loop value DO EF1Process 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); forexample, event 1 and event 2):

WHEN (START WITH event 1 AND event 2) DO EF1

• Initiating one or more EF s following the occurrence of a designated start event:

WHEN (START ) DO EF1


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, EFy follows EFx regardless

of the ending status of EFx. 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(EFx) = ANY ) DO EFy

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 EF1 had

three different ending statuses, we can write:

WHEN (ES(EF1) = end stat 1) DO EF2



This indicates that EF2, EF3, and EF4 are the different branches that are enabled

depending on the ending status of EF1.

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 EF1 finishes with status value, EF2,EF3 and EF4 will all be requested to start as soon as they are enabled, i.e. when


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

WHEN (ES(EF1) = value) DO EF2 & EF3 & EF4

• Synchronous spawning: For instance, when EF1 finishes with status value, EF2,EF3 and EF4 will all be requested to start exactly at the same time assumingthat they are all enabled (SYNC indicates the synchronisation).

WHEN (ES(EF1) = value) DO SY NC (EF2 & EF3 & EF4)

Rendezvous Rules

Rendezvous rules are used to synchronize the end of spawning rules. For example, if

EF5 starts after EF2 finishes with a status of value 24, EF3 finishes with a status of

value 3, and EF4 finishes with a status of value 4, then the rendezvous rule is written

as:

WHEN (ES(EF2) = value 2 AND ES(EF3) = value 3

AND ES(EF4) = value 4) DO EF5

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(EF1) = loop value) DO EF1

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


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

WHEN (ES(EF1) = end stat x AND ES(EF2) = end stat y) DO FINISH

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].

<act ion> : := <run t ime cho i ce> <unordered set><run t ime cho i ce> : := compound−act ion−id = ( process−step−id XOR

process−step−id <o the r run t ime s t ep s> )<o the r run t ime s t ep s> : := XOR process−step−id <

o the r run t ime s t ep s> n i l<unordered−set> : := compound−act ion−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> }<o t h e r u n o r d e r e d s e t s t e p s> : := 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(EF1) = end stat 1) DO S = (EF2 XOR EF3 XOR EF4)


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(EF1) = end stat 1) DO S = {EF2, EF3, EF4}

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


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.


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.

( c o n d i t i o n a l ?a )< c o n d i t i o n a l a c t i v i t y > : := ( f o r a l l (? s ? s2 )

( i f f (do ?a ? s ? s2 )< s i m p l e c o n d i t i o n a l >))

( p a r t i a l c o n d i t i o n a l ?a )< p a r t i a l c o n d i t i o n a l > : := ( f o r a l l (? s ? s2 < v a r i a b l e >+)

( i f f (do ?a ? s ? s2 )< c o n d i t i o n a l f o r m u l a >))

Grammar 5.4: Grammar for auxiliary rules in PSL.

< s i m p l e c o n d i t i o n a l > : := ( i f < s imp l e s ta t e ax i om >< v a r i a t i o n f o r m u l a >)

< c o n d i t i o n a l f o r m u l a > : := ( i f < s tate ax iom >< 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 beaccessed via: http://www.mel.nist.gov/psl/psl-ontology/part42/grammars/state_variation.bnf.html

http://www.mel.nist.gov/psl/psl-ontology/part42/grammars/state_variation.bnf.html

http://www.mel.nist.gov/psl/psl-ontology/part42/grammars/state_variation.bnf.html


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].


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 activitytree.

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

• 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

http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_core


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

http://code.google.com/p/colore/source/browse/trunk/ontologies/cimosa/cimosa.clif



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 BusinessProcess behaviour.

Business Processes (BP) Partially ordered set of enterprise activities that can beexecuted to achieve some desired end-result in pursuitof 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 occurrenceof 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 consumeinputs 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 inaccordance.

Enterprise Object Construct that represents a piece of information in thedomain of the enterprise that describes a generalized ora real or an abstract entity, which can be conceptualizedas being a whole.

Event A solicited or unsolicited fact indicating a state changein the enterprise.

Occurrence A single, actual realization of an entity in the real world.


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

Term Description

begin(x) Performs an action (such as carrying out a businessprocess or enterprise activity) when invoked.

business process(x) Partially ordered set of enterprise activities thatcan 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 thatconsume inputs and allocate time and resources toproduce 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)


• 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 1′′, 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 (START WITH event− i AND event− j) DO EF1

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))∧


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 (START ) DO EF1

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(EFx) = ANY ) DO EFy

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)


Conditional Sequential Rules

Recall that the original rule is stated as:




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:

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






Spawning Rules

Recall that spawning rules come in two different forms: asynchronous and synchronous.

The asynchronous form is defined in such a way that EF2, EF3 and EF4 will all be


requested to start as soon as they are enabled after EF1 finishes with a status value:

WHEN (ES(EF1) = value) DO EF2 & EF3 & EF4

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 EF2, EF3 and

EF4 occurs, so the axiom can be defined as follows:

∀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 EF1 occurs before EF2, EF3 and EF4 is preserved

through the use of the precedes(o1, o2), precedes(o1, o3), and precedes(o1, o4) relations,

respectively. Similarly, for synchronous spawning, EF2, EF3 and EF4 will all be re-

quested to start exactly at the same time assuming that they are all enabled (SYNC

indicates the synchronization):

WHEN (ES(EF1) = value) DO SY NC (EF2 & EF3 & EF4)

To write this in first-order logic, we can assume that EF2, EF3 and EF4 start at the

same time point. Thus, we use the beginof(o) function in PSL to indicate that the


starting time points of EF2, EF3 and EF4 are the same:




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, EF5 starts only

when EF2 finishes with a status of value 2, EF3 finishes with a status of value 3, and

EF4 finishes with a status of value 4.

WHEN (ES(EF2) = value 2 AND ES(EF3) = value 3

AND ES(EF4) = value 4) DO EF5

Since the ending time points for the enterprise functions EF2, EF3 and EF4 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:

∀o2∀o3∀o4∀x∀y∀z ((holds(“value 2′′, o2)∧


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

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


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(EF1) = loop value) DO EF1

We can axiomatize this trivially in first-order as:

∀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


occurrence ordering theory, Tsoo5, in PSL and attempt to use the soo(s, a) relation6 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(EF1) = end stat x AND ES(EF2) = end stat y) DO FINISH

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))∧

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.

http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_soo/soo.clif

http://code.google.com/p/colore/source/browse/trunk/ontologies/psl_soo/soo.clif

http://www.mel.nist.gov/psl/psl-ontology/part13/soo.th.html


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(EF1) = end stat 1) DO S = (EF2 XOR EF3 XOR EF4)

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.


∃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




¬(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(EF1) = end stat 1) DO S = {EF2, EF3, EF4}

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:




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.


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 Gruninger in [21] is to utilize a


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].


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-


tion of a modelling language that is itself compliant, or (ii) for a modellinglanguage claiming qualified compliance, if the model uses only those modellinglanguage 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 thatreality.

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.


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

http://www.servicedathome.com

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 bysupporting 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.

http://www.servicedathome.com/

http://www.hunchmanifest.com/

http://www.nserc-crsng.gc.ca/Professors-Professeurs/RPP-PP/Engage-engagement_eng.asp

http://www.nserc-crsng.gc.ca/Professors-Professeurs/RPP-PP/Engage-engagement_eng.asp


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 ontology3 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 andare designed with the intention to support broad semantic interoperability between other ontologies.

http://www.servicedathome.com/

http://semanticarts.com/gist/


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.

http://www.amazon.com

http://www.sears.com

http://www.franz.com/agraph/allegrograph/


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.


Amazon.com

Sears.com

Amazon.com API

Sears.com API XML Response

XML Response

Amazon.com API Response OWL Ontology

Sears.com API Response OWL Ontology

ServicedAtHome Mapping Front-End

Query from User

ServicedAtHome Mapping Back-End

Mapped Results

Response to User

Amazon.com API Response RDF Ontology

Sears.com Response RDF Ontology

Allegrograph RDF Data Store

API Queries

Figure 6.1: Relationship between the different API technologies and ontologies.


• Developing the vendor API ontologies through the examination of sample productdata.

• 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:


1. Amazon’s Product Advertising API ScratchPadThis 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 formof a single line query. Refer to Appendix D.3 for the queries use to retrieve theAmazon product information.

2. Git for Windows (to utilize the cURL tool)Since Sears only allows its API to be queried through cURL commands, we wererequired 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 Protege Ontology 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, Protege version 4.2.0 was used and can be found at http://protege.stanford.edu/.

5https://sellercentral.amazon.com/gp/homepage.html

http://associates-amazon.s3.amazonaws.com/scratchpad/index.html

http://git-scm.com/

http://protege.stanford.edu/

http://protege.stanford.edu/

https://sellercentral.amazon.com/gp/homepage.html


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)

http://www.amazon.com/b/ref=sr_aj?node=552794&ajr=0


Table 6.1: Excerpt of metadata tags found in the Amazon XML result set, along withthe names used in OWL relations.

Amazon XML Tag OWL Relation Name Functional?

ASIN ASIN YesDetailPageURL DetailPageURL Yes

ItemLink ItemLink YesDescription Description Yes

URL URL YesItemAttributes ItemAttributes Yes

Binding Binding YesBrand Brand Yes

CatalogNumberList CatalogNumberList YesCatalogNumberListElement CatalogNumberListElement Yes

EAN EAN YesEANList EANList Yes

EANListElement EANListElement YesFeature Feature Yes

ItemDimensions ItemDimensions YesHeight Height YesLength Length YesWeight Weight YesWidth Width YesLabel Label Yes

ListPrice ListPrice YesAmount Amount Yes

CurrencyCode CurrencyCode YesFormattedPrice FormattedPrice YesManufacturer Manufacturer Yes

Model Model YesMPN MPN Yes

PackageDimensions PackageDimensions YesPackageQuantity PackageQuantity Yes

PartNumber PartNumber YesProductGroup ProductGroup Yes

ProductTypeName ProductTypeName YesPublisher Publisher Yes

SKU SKU YesStudio Studio YesTitle Title YesUPC UPC Yes

UPCList UPCList YesUPCListElement UPCListElement Yes

Warranty Warranty Yes


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 thenames used in OWL relations.

Sears XML Tag OWL Relation Name Functional?

PartNumber PartNumber YesName Name Yes

CutPrice CutPrice YesSkuPartNumber SkuPartNumber Yes

BrandName BrandName YesCutPrice CutPrice Yes

DisplayPrice DisplayPrice YesCatEntryId CatEntryId Yes

MfgPartNumber MfgPartNumber YesKsnValue KsnValue Yes

6http://www.sears.com/shc/s/smv_10153_12605

http://www.sears.com/tools-air-compressors-air-tools/c-1020134

http://www.sears.com/shc/s/smv_10153_12605


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 whetherthere 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 ontologieswith 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 : Publisher ≡ Sears : BrandName (6.3.1)

Amazon : Brand ≡ Sears : BrandName (6.3.2)


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 empty7. 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 : MfgPartNumber (6.3.5)

Amazon : PartNumber ≡ Sears : MfgPartNumber (6.3.6)

Amazon : MPN ≡ Sears : MfgPartNumber (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 isinconsistent with Amazon.


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 : Title ≡ Sears : Title (6.3.8)

Amazon : Title ≡ 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 : Feature ≡ Sears : ShortDescription (6.3.10)

Amazon : Feature ≡ 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 : ProductDetail (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 : Price ≡ Sears : RegularPrice (6.3.13)


Amazon : Price ≡ Sears : SalePrice (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 OWLontologies.

Amazon Relation Sears Relation

amazon:Publisher / amazon:Brand sears:BrandNameamazon:Publisher sears:BrandName

amazon:Brand sears:BrandNameamazon:SKU sears:Sku

amazon:Model sears:MfgPartNumberamazon:PartNumber sears:MfgPartNumber

amazon:MPN sears:MfgPartNumberamazon:Title sears:Titleamazon:Title sears:DescriptionName

amazon:Feature sears:ShortDescriptionamazon:Feature sears:LongDescription

amazon:Manufacturer sears:BrandNameamazon:Heightamazon:Lengthamazon:Widthamazon:Weightamazon:Offer sears:ProductDetailamazon:EANamazon: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


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 : hasMPN ≡ gist : ProductOffering

gr : hasEAN UCC − 13 ≡ gist : hasBeenAllocated

gr : hasEAN UCC − 13 ≡ gist : ID

gr : hasStockKeepingUnit ≡ gist : ID


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 : hasFeature

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 : ProductOffering

Likewise, the ProductOrService relation in GoodRelations describes all products and

classes, which is equivalent to the ProductOffering relation in GIST.

gr : ProductOrService ≡ gist : ProductOffering


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 : Term

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 v gist : Magnitude

gr : depth v gist : Magnitude

gr : width v gist : Magnitude

The weight and Weight relations in GoodRelations and gist are also mapped together.

gr : weight ≡ gist : Weight

9The Magnitude relation indicates a scalar value which is either measured, estimated or set as areference value [53].


Table 6.4: Direct mappings between relations found in the GoodRelations and HomeSer-vices/GIST OWL ontologies.

GoodRelations HomeServices/GIST Relation

gr:hasMakeAndModel gist:ProductOfferinggr:StockKeepingUnit gist:ID

gr:ProductOrServiceModel gist:ProductOfferinggr:hasMPN gist:ProductOffering

gr:name gist:namegr:description gist:hasFeature

gr:hasManufacturer gist:producedBygr:description gist:Offering

gr:ProductOrService gist:ProductOfferinggr:height declare subclassof gist:Magnitudegr:depth declare subclassof gist:Magnitudegr:width declare subclassof gist:Magnitudegr:weight gist:Weight

gr:Offering gist:Termgr:hasEAN UCC-13 gist:hasBeenAllocatedgr:hasEAN UCC-13 gist:IDgr: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


(XHTML) web pages. Transformation algorithms are specified in XSL format in the

<head> 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 RDFValidation Service: http://www.w3.org/RDF/Validator/.

11The Windows binaries of the xsltproc tool provided by Igor Zlatkovic were used to apply thestylesheets to the raw XML data. Instructions on how to apply the stylesheets to product data can befound in Appendix D.4.2.

http://xmlsoft.org/XSLT/xsltproc2.html

http://www.w3.org/RDF/Validator/

http://www.zlatkovic.com/libxml.en.html


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.

<x s l : t e m p l a t e match=”/”><x s l : e l e m e n t name=”rdf:RDF” xmlns :x s l=” ht tp : //www. w3 . org /1999/

XSL/Transform” xmln s : f o a f=” ht tp : //xmlns . com/ f o a f /0 .1/ ”xmlns : rd f=” ht tp : //www. w3 . org /1999/02/22− rdf−syntax−ns#”xmlns : rd f s=” ht tp : //www. w3 . org /2000/01/ rdf−schema#”xmlns : s ea r s=” ht tp : //www. example . org /schemas/ s e a r s#”>

<r d f : D e s c r i p t i o n><x s l : a t t r i b u t e name=” rd f : about ”><x s l : v a l u e−o f

s e l e c t=”/ ProductDeta i l / SoftHardProductDeta i l s /DescriptionName ” /></ x s l : a t t r i b u t e>

<s e a r s : P r o d u c t D e t a i l><s ea r s :So f tHardProduc tDeta i l s><sears:PartNumber><x s l : v a l u e−o f s e l e c t=”/ ProductDeta i l / SoftHardProductDeta i l s /

PartNumber” /></ sears:PartNumber>

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.

<I temAttr ibutes><Binding>Tools &amp ; Home Improvement</ Binding><Brand>Black &amp ; Decker</Brand><CatalogNumberList><CatalogNumberListElement>383724</CatalogNumberListElement><CatalogNumberListElement>LDX112C</CatalogNumberListElement>

</CatalogNumberList><EAN>0999900010328</EAN>. . .

</ ItemAttr ibutes>


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.

<rdf:RDF xmlns : rd f=” ht tp : //www. w3 . org /1999/02/22− rdf−syntax−ns#”><r d f : D e s c r i p t i o n rd f : abou t=”B004443WVW”><amazon:ItemAttr ibutes xmlns:amazon=” ht tp : //www. example . org /

schemas/amazon#” rdf :parseType=” Resource ”><amazon:Binding>Tools &amp ; Home Improvement</

amazon:Binding><amazon:Brand>Black &amp ; Decker</amazon:Brand><amazon:CatalogNumberList rd f :parseType=” Resource ”><amazon:CatalogNumberListElement>

383724</amazon:CatalogNumberListElement><amazon:CatalogNumberListElement>

LDX112C</amazon:CatalogNumberListElement></amazon:CatalogNumberList><amazon:EAN>0999900010328</amazon:EAN>. . .</ amazon:ItemAttr ibutes>

</ r d f : D e s c r i p t i o n></rdf:RDF>

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 OWLontologies, the conversion to RDF syntax did not affect the semantics of the ontologies.


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.

HSO

e.g., gist:ProducedBy

e.g., gr:hasBrand

Amazon

Sears

e.g., Amazon:Brand

e.g., Sears:BrandNameGoodRelations

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 todisplay in print.


Mapping 6.4: Mapping between HSO and Amazon.

g i s t : ProductOf fe r ing owl : equ iva l entProper ty amazon : Pub l i she r .g i s t : ProductOf fe r ing owl : equ iva l entProper ty amazon : Brand .g i s t : ProductOf fe r ing owl : equ iva l entProper ty amazon : hasModel .g i s t : ProductOf fe r ing owl : equ iva l entProper ty amazon :MPN.g i s t : name owl : equ iva l entProper ty amazon : T i t l e .g i s t : hasFeature owl : equ iva l entProper ty amazon : Feature .g i s t : hasFeature owl : equ iva l entProper ty amazon : Feature .g i s t : producedBy owl : equ iva l entProper ty amazon : Manufacturer .g i s t : Term owl : equ iva l entProper ty amazon : Of f e r .g i s t : hasBeenAllocated owl : equ iva l entProper ty amazon :EAN.g i s t : ID owl : equ iva l entProper ty amazon :EAN.g i s t : currencyValue owl : equ iva l entProper ty amazon : Pr i ce .

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.

g i s t : ProductOf fe r ing owl : equ iva l entProper ty s e a r s : BrandName .g i s t : ProductOf fe r ing owl : equ iva l entProper ty s e a r s : MfgPartNumber .g i s t : ProductOf fe r ing owl : equ iva l entProper ty s e a r s : MfgPartNumber .g i s t : name owl : equ iva l entProper ty s e a r s : T i t l e .g i s t : hasFeature owl : equ iva l entProper ty s e a r s : Shor tDesc r ip t i on .g i s t : hasFeature owl : equ iva l entProper ty s e a r s : LongDescr ipt ion .g i s t : producedBy owl : equ iva l entProper ty s e a r s : BrandName .g i s t : Term owl : equ iva l entProper ty s e a r s : ProductDeta i l .g i s t : currencyValue owl : equ iva l entProper ty s e a r s : RegularPr ice .g i s t : currencyValue owl : equ iva l entProper ty s e a r s : Sa l ePr i c e .

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.


amazon : Pub l i she r owl : equ iva l entProper ty s e a r s : BrandName .amazon : Brand owl : equ iva l entProper ty s e a r s : BrandName .amazon :SKU owl : equ iva l entProper ty s e a r s : Sku .amazon : Model owl : equ iva l entProper ty s e a r s : MfgPartNumber .amazon : PartNumber owl : equ iva l entProper ty s e a r s : MfgPartNumber .amazon :MPN owl : equ iva l entProper ty s e a r s : MfgPartNumber .amazon : T i t l e owl : equ iva l entProper ty s e a r s : T i t l e .amazon : T i t l e owl : equ iva l entProper ty s e a r s : DescriptionName .amazon : Feature owl : equ iva l entProper ty s e a r s : Shor tDesc r ip t i on .amazon : Feature owl : equ iva l entProper ty s e a r s : LongDescr ipt ion .amazon : Manufacturer owl : equ iva l entProper ty s e a r s : BrandName .amazon : Of f e r owl : equ iva l entProper ty s e a r s : ProductDeta i l .amazon : Pr i ce owl : equ iva l entProper ty s e a r s : RegularPr ice .amazon : Pr i ce owl : equ iva l entProper ty s e a r s : Sa l ePr i c e .

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 : equ iva l entProper ty g i s t : ProductOf fe r ing .gr : StockKeepingUnit owl : equ iva l entProper ty g i s t : ID .gr : ProductOrServiceModel owl : equ iva l entProper ty g i s t :

ProductOf fe r ing .gr :hasMPN owl : equ iva l entProper ty g i s t : ProductOf fe r ing .gr : hasName owl : equ iva l entProper ty g i s t : name .gr : d e s c r i p t i o n owl : equ iva l entProper ty g i s t : hasFeature .gr : hasManufacturer owl : equ iva l entProper ty g i s t : producedBy .gr : d e s c r i p t i o n owl : equ iva l entProper ty g i s t : O f f e r i ng .gr : ProductOrService owl : equ iva l entProper ty g i s t : ProductOf fe r ing .gr : weight owl : equ iva l entProper ty g i s t : Weight .gr : O f f e r i ng owl : equ iva l entProper ty g i s t : Term .gr : hasEAN UCC−13 owl : equ iva l entProper ty g i s t : hasBeenAllocated .gr : hasEAN UCC−13 owl : equ iva l entProper ty g i s t : ID .gr : hasCurrencyValue owl : equ iva l entProper ty g i s t : currencyValue .


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 andAmazon.

• Section 6.5.2 describes a query that finds the cheapest products offered by Searsand Amazon based on a keyword.

• Section 6.5.3 describes a query that finds the average price of products (specifiedby keyword) offered by Sears and Amazon.

• Section 6.5.4 describes a query that finds the average price of all products offeredby Sears and Amazon.

• Section 6.5.6 describes a query that finds the average price of products offered bySears and Amazon based on a keyword.

• Section 6.5.7 describes a query that finds the combined product attributes of aproduct offered by both vendors.

• Section 6.5.5 describes a federated query that combines the product data withinformation from DBPedia.


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 : <http :// o n t o l o g i e s . s emant i ca r t s . com/ gist#>PREFIX hso : <http ://www. example . org /schemas/hso#>PREFIX rdf : <http ://www. w3 . org /1999/02/22−rdf−syntax−ns#>PREFIX rdfs : <http ://www. w3 . org /2000/01/ rdf−schema#>PREFIX sears : <http ://www. example . org /schemas/ sears#>PREFIX amazon : <http ://www. example . org /schemas/amazon#>SELECT DISTINCT ?mfgno ? minpr iceWHERE {

? sea r sproduct sears : MfgPartNumber ?mfgno .? s ea r sproduct sears : S a l ePr i c e ? s e a r s p r i c e .

BIND ( xsd : decimal (? s e a r s p r i c e ) AS ? minpr ice )OPTIONAL{

? amazonproduct amazon :MPN ?mfgno .?amazontemp amazon : L i s tPr i ceFormattedPr i ce ? amazonprice .? amazonproduct amazon : L i s t P r i c e ?amazontemp .BIND ( xsd : decimal ( substr (? amazonprice , 2 ) ) AS ? o t h e r p r i c e )FILTER(? o t h e r p r i c e < ? minpr ice )

}FILTER ( ! bound (? o t h e r p r i c e ) ) .

}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


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 : <http :// o n t o l o g i e s . s emant i ca r t s . com/ gist#>PREFIX hso : <http ://www. example . org /schemas/hso#>PREFIX rdf : <http ://www. w3 . org /1999/02/22−rdf−syntax−ns#>PREFIX rdfs : <http ://www. w3 . org /2000/01/ rdf−schema#>PREFIX sears : <http ://www. example . org /schemas/ sears#>PREFIX amazon : <http ://www. example . org /schemas/amazon#>SELECT DISTINCT ?mfgno ? minpr ice ? prodTi t l eWHERE {

? sea r sproduct sears : MfgPartNumber ?mfgno .? s ea r sproduct sears : S a l ePr i c e ? s e a r s p r i c e .

BIND ( xsd : decimal (? s e a r s p r i c e ) AS ? minpr ice )? s ea r sproduct sears : DescriptionName ? prodTi t l e .OPTIONAL{

? amazonproduct amazon :MPN ?mfgno .?amazontemp amazon : L i s tPr i ceFormattedPr i ce ? amazonprice .? amazonproduct amazon : L i s t P r i c e ?amazontemp .BIND ( xsd : decimal ( substr (? amazonprice , 2 ) ) AS ? o t h e r p r i c e )FILTER(? o t h e r p r i c e < ? minpr ice )? amazonproduct amazon : T i t l e ? prodTi t l e .

}FILTER ( ! bound (? o t h e r p r i c e ) ) .FILTER regex (? prodTit le , ” d r i l l ” , ” 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


titles for both vendors and their respective average prices. Table D.3 in Appendix D.6

lists the results of this query.

PREFIX gist : <http :// o n t o l o g i e s . s emant i ca r t s . com/ gist#>PREFIX hso : <http ://www. example . org /schemas/hso#>PREFIX rdf : <http ://www. w3 . org /1999/02/22−rdf−syntax−ns#>PREFIX rdfs : <http ://www. w3 . org /2000/01/ rdf−schema#>PREFIX sears : <http ://www. example . org /schemas/ sears#>PREFIX amazon : <http ://www. example . org /schemas/amazon#>SELECT ? s e a r s T i t l e ? amazonTitle (AVG(? sear sVa l ) AS ? sear savg ) (

AVG(? amazonVal ) AS ?amazonavg )WHERE{

? sea r sproduct sears : DescriptionName ? s e a r s T i t l e .? s ea r sproduct sears : S a l ePr i c e ? s e a r s p r i c e .BIND ( xsd : decimal (? s e a r s p r i c e ) AS ? sear sVa l )? amazonproduct amazon : T i t l e ? amazonTitle .?amazontemp amazon : L i s tPr i ceFormattedPr i ce ? amazonprice .? amazonproduct amazon : L i s t P r i c e ?amazontemp .BIND ( xsd : decimal ( substr (? amazonprice , 2 ) ) AS ?amazonVal )FILTER regex (? s e a r s T i t l e , ” d r i l l ” , ” i ” ) .FILTER regex (? amazonTitle , ” d r i l l ” , ” i ” ) .

}GROUP BY ? s e a r s T i t l e ? 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:MPNmay 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.


PREFIX gist : <http :// o n t o l o g i e s . s emant i ca r t s . com/ gist#>PREFIX hso : <http ://www. example . org /schemas/hso#>PREFIX rdf : <http ://www. w3 . org /1999/02/22−rdf−syntax−ns#>PREFIX rdfs : <http ://www. w3 . org /2000/01/ rdf−schema#>PREFIX sears : <http ://www. example . org /schemas/ sears#>PREFIX amazon : <http ://www. example . org /schemas/amazon#>SELECT ?mfgno (AVG(? s ear sVa l ) AS ? sear savg ) (AVG(? amazonVal ) AS

?amazonavg )WHERE{

? sea r sproduct sears : MfgPartNumber ?mfgno .? s ea r sproduct sears : DescriptionName ? s e a r s T i t l e .? s ea r sproduct sears : S a l ePr i c e ? s e a r s p r i c e .BIND ( xsd : decimal (? s e a r s p r i c e ) AS ? sear sVa l )

? amazonproduct amazon :MPN ?mfgno .? amazonproduct amazon : T i t l e ? amazonTitle .?amazontemp amazon : L i s tPr i ceFormattedPr i ce ? amazonprice .? amazonproduct amazon : L i s t P r i c e ?amazontemp .BIND ( xsd : decimal ( substr (? amazonprice , 2 ) ) AS ?amazonVal )

}GROUP BY ?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

http://www.http://dbpedia.org


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 : <http :// o n t o l o g i e s . s emant i ca r t s . com/ gist#>PREFIX hso : <http ://www. example . org /schemas/hso#>PREFIX rdf : <http ://www. w3 . org /1999/02/22−rdf−syntax−ns#>PREFIX rdfs : <http ://www. w3 . org /2000/01/ rdf−schema#>PREFIX sears : <http ://www. example . org /schemas/ sears#>PREFIX amazon : <http ://www. example . org /schemas/amazon#>PREFIX dbpedia−owl : <http :// dbpedia . org / r e sou r c e / c l a s s e s#>PREFIX dbpprop : <http :// dbpedia . org / property/>

SELECT ? productBrand ? foundingYear ? s e a r s t i t l e ? amazont i t l e ?brandDBPediaURI

WHERE {{SELECT ? productBrand ? s e a r s t i t l e ? amazont i t l eWHERE {

? sea r sproduct sears : BrandName ? productBrand .? s ea r sproduct sears : DescriptionName ? s e a r s t i t l e .? amazonproduct amazon : Brand ? productBrand .? amazonproduct amazon : T i t l e ? amazont i t l e .BIND(URI(CONCAT( ” http :// dbpedia . org / r e s ou r c e /” , ?

productBrand ) ) AS ?brandDBPediaURI ) . } }SERVICE <http :// dbpedia . org / sparq l> {SELECT DISTINCT ? foundingYear

WHERE {?brandDBPediaURI <http :// dbpedia . org / property /

foundation> ? foundingYear .}FILTER (? foundingYear>1500 && (2013−? foundingYear ) >=

10 )}ORDER BY DESC(? foundingYear ) ASC(? productBrand )LIMIT 1000

Code 6.12: Federated SPARQL query to combine the product with DBPedia data.


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:MPNmay 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 : <http :// o n t o l o g i e s . s emant i ca r t s . com/ gist#>PREFIX hso : <http ://www. example . org /schemas/hso#>PREFIX rdf : <http ://www. w3 . org /1999/02/22−rdf−syntax−ns#>PREFIX rdfs : <http ://www. w3 . org /2000/01/ rdf−schema#>PREFIX sears : <http ://www. example . org /schemas/ sears#>PREFIX amazon : <http ://www. example . org /schemas/amazon#>SELECT ?mfgno (AVG(? s ear sVa l ) AS ? sear savg ) (AVG(? amazonVal ) AS

?amazonavg )WHERE{

? sea r sproduct sears : MfgPartNumber ?mfgno .? s ea r sproduct sears : DescriptionName ? s e a r s T i t l e .? s ea r sproduct sears : S a l ePr i c e ? s e a r s p r i c e .BIND ( xsd : decimal (? s e a r s p r i c e ) AS ? sear sVa l )

? amazonproduct amazon :MPN ?mfgno .? amazonproduct amazon : T i t l e ? amazonTitle .?amazontemp amazon : L i s tPr i ceFormattedPr i ce ? amazonprice .? amazonproduct amazon : L i s t P r i c e ?amazontemp .BIND ( xsd : decimal ( substr (? amazonprice , 2 ) ) AS ?amazonVal )FILTER ( regex (? s e a r s T i t l e , ” d r i l l ” , ” i ” ) | | regex (? amazonTitle ,

” d r i l l ” , ” i ” ) )}GROUP BY ?mfgno

Code 6.13: SPARQL query to find the average price of products for both vendors thatare ‘drills.’


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 : <http :// o n t o l o g i e s . s emant i ca r t s . com/ gist#>PREFIX hso : <http ://www. example . org /schemas/hso#>PREFIX rdf : <http ://www. w3 . org /1999/02/22−rdf−syntax−ns#>PREFIX rdfs : <http ://www. w3 . org /2000/01/ rdf−schema#>PREFIX sears : <http ://www. example . org /schemas/ sears#>PREFIX amazon : <http ://www. example . org /schemas/amazon#>SELECT ?mfgno ? amazonTitle ? amazondescr ipt ion ? s e a r s T i t l e ?

s e a r s d e s c r i p t i o n ? s e a r s d e s c r i p t i o n 2WHERE{

? sea r sproduct sears : MfgPartNumber ?mfgno .? s ea r sproduct sears : LongDescr ipt ion ? s e a r s d e s c r i p t i o n .? s ea r sproduct sears : Shor tDesc r ip t i on ? s e a r s d e s c r i p t i o n 2 .? s ea r sproduct sears : DescriptionName ? s e a r s T i t l e .

? amazonproduct amazon :MPN ?mfgno .? amazonproduct amazon : Feature ? amazondescr ipt ion .

? amazonproduct amazon : T i t l e ? amazonTitle .}ORDER BY ?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


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


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 SemanticWeb; 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


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:

http://www.productontology.org/


• gr:category

• gr:color

• gr:condition

• gr:depth

• gr:hasEAN UCC-13

• gr:hasGTIN-14

• gr:hasMPN

• gr:hasManufacturer

• gr:hasStockKeepingUnit

• gr:height

• gr:isAccessoryOrSparePartFor

• gr:isConsumableFor

• gr:isSimilarTo

• gr:weight

• 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=en17http://www.google.com/shopping

https://support.google.com/merchants/answer/1705911?hl=en

http://www.google.com/shopping


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


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


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 Chapter 3, 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-


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 Chapter 6 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


storage and organization of lemmas and theory subsets to help improve theorem prover

performance. As we have seen in Chapters 3 and 4, 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 Benzmuller and 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

http://www.w3.org/2007/Talks/0130-sb-W3CTechSemWeb/

http://www.w3.org/2007/Talks/0130-sb-W3CTechSemWeb/

Bibliography 169

[8] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and Francois Yergeau.

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

Gruninger. 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 Gruninger. Enterprise Modeling. AI Magazine, 19(3):109–

121, 1998.

http://www.w3.org/2004/01/rdxh/spec

http://www.mel.nist.gov/psl/faq.html

http://www.mel.nist.gov/psl/faq.html

Bibliography 170

[18] Andres Garcıa-Silva, Leyla Jael Garcıa-Castro, Alexander Garcıa-Castro, Oscar Cor-

cho, and Asuncion Gomez-Perez. 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 Gruninger. The Ontological Stance for a Manufacturing Scenario. J. Cases

on Inf. Techn., 11(4):1–25, 2009.

[22] Michael Gruninger. 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 Gruninger. 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 Gruninger and Carmen Chui. Mereological Bundles and Temporary Part-

hood. Manuscript in preparation, 2013.

[25] Michael Gruninger and Carmen Chui. Processes and Participation. Manuscript in

preparation, 2013.

[26] Michael Gruninger and Carmen Chui. Theory Foliations. Manuscript in preparation,

2013.

Bibliography 171

[27] Michael Gruninger 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 Gruninger, Torsten Hahmann, Ali Hashemi, and Darren Ong. Ontology

Verification with Repositories. In FOIS, pages 317–330, 2010.

[29] Michael Gruninger, Torsten Hahmann, Ali Hashemi, Darren Ong, and Atalay

Ozgovde. Modular First-Order Ontologies via Repositories. Applied Ontology,

7(2):169–209, 2012.

[30] Michael Gruninger and Joseph B. Kopena. Semantic Integration Through Invariants.

AI Mag., 26(1):11–20, March 2005.

[31] Michael Gruninger and Christopher Menzel. The Process Specification Language

(PSL) Theory and Applications. AI Mag., 24(3):63–74, September 2003.

[32] Michael Gruninger and 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.

http://www.w3.org/TR/grddl-primer/


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 fur Informatik (IBFI), Schloss Dagstuhl, Germany.

[43] Megan Katsumi and Michael Gruninger. Theorem Proving in the Ontology Lifecycle.

In KEOD, pages 37–49, 2010.

http://wiki.goodrelations-vocabulary.org/index.php?title=Documentation&oldid=2189



http://www.productontology.org/

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.

http://ontologies.semanticarts.com/gist/gistCore6.7.owl

http://ontologies.semanticarts.com/gist/gistCore6.7.owl

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.

http://www.cs.miami.edu/~tptp/OverviewOfATP.html

http://www.cs.miami.edu/~tptp/OverviewOfATP.html

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, Francois B. Vernadat, and Kurt Kosanke. The CIMOSA Business

Modelling Process. Comput. Ind., 27(2):123–142, October 1995.

[67] Antoine Zimmermann, Markus Krotzsch, Jerome Euzenat, 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 APIis a set of Hypertext Transfer Protocol (HTTP) request messages, along with adefinition of the structure of response messages, which is usually in an ExtensibleMarkup 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 themodular structure found in software systems. It consists of list of unit declarationsand 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 logicalconsequence of a set of statements, the axioms and hypotheses. ATP systems arecapable of solving difficult problems under the aid of domain experts, and requireproblems to be written in a logical form in order to output proofs. Additionalinformation can be found in [59]. 182

BFO The Basic Formal Ontology is a small, upper level ontology, developed by BarrySmith 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 specificationlanguage based on first-order logic with induction, with support for partial functionsand subsorting. It comprises of basic specifications (for the specification of singlesoftware 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 theInternet). 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 andallows the creation of executable enterprise models in computer integrated manu-facturing (CIM) programs. It was developed in 1992 and has been standardized by

176

http://www.ifomis.org/bfo

http://www.ifomis.org/bfo

http://www.informatik.uni-bremen.de/cofi/wiki/index.php/CASL

http://www.informatik.uni-bremen.de/cofi/wiki/index.php/CASL

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 syntaxesfound 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 (aset of names and sequence names), and an interpretation of that vocabulary. Forexample, to say the following sentence, “A cat is on a mat,” we can write this inCommon Logic as (exists ((x Cat) (y Mat)) (On x y)), which readsas “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-orderontologies that serves as a test bed for ontology evaluation and integration tech-niques, and that can support the design, evaluation, and application of ontologiesin 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 thespecification of first-order ontologies and knowledge bases, and its details can befound in the ISO 24707:2007 document [41]. It consists of three dialects: theConceptual Graph Interchange Format (CGIF), the Common Logic InterchangeFormat (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 forany sentence σ ∈ L(T1),

T2 |= σ iff T1 |= σ

. 11

conservativity triangle Adopted from [48], a graphical representation of relative con-sistency proofs, where the given theories T , T ′, and T

′′and signature morphisms

σ : T → T ′, ι1 : T ′ → T′′

and ι2 : T ′ → T , such that T is a conservativity triangleand 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 knowledgethat is used to perform human-like reasoning. Parts of the project are released asOpenCyc. 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 firstmodule of the WonderWeb foundational ontologies library that aims at capturingthe 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 everyinstant 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 σ ∈ L(T1),

if T1 |= σ, then T2 |= σ

. 11

faithful interpretation Adopted from [29], an interpretation π of a theory T1 into atheory T2 is a faithful interpretation, if and only if, for any sentence σL(T1),

T1 6|= σ ⇒ T2 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 closedunder logical entailment. 11

gist The gist ontology is minimalist upper ontology designed in OWL to have maximumcoverage 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 annotatingofferings and other aspects of e-commerce on the Web. It is written in OWL-DL andprovides a standard vocabulary for product, price, store, and company data thatcan be embedded into Web pages. Additional information can be found via http://www.heppnetz.de/ontologies/goodrelations/v1.html. 135, 138–141, 148, 159

http://semanticarts.com/gist/

http://www.heppnetz.de/ontologies/goodrelations/v1.html

http://www.heppnetz.de/ontologies/goodrelations/v1.html

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 markupformat that is a W3C Recommendation which enables users to obtain RDF triplesout of XML documents, including XHTML. Additional information can be foundvia http://www.w3.org/TR/grddl-primer/. 142, 143

hierarchy Adopted from [29], a hierarchy, H = 〈H,≤〉, is a partially ordered, finite setof theories H = T1, . . . , Tn, such that:

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-profitorganization that promotes the interdisciplinary research and international collab-oration of the following fields: philosophical ontology, linguistics, logic, cognitivescience, and computer science. The organization is interested in educating the com-munity on what ontologies are and how they can be effectively utilized, supportingthe development of collaborations between research and industry, and supportingthe publication of journals and books. Additional information can be found viahttp://www.iaoa.org/. 91, 165

IDEF The Integration DEFinition family of modelling languages is used in the field ofsystems and software engineering, which include functional modelling, data sim-ulation, object-oriented analysis/design, and knowledge acquisition. Additionalinformation can be found via http://www.idef.com/. 120, 179

IDEF3 The Integrated DEFinition for Process Description Capture Method is a businessprocess modelling method that is a scenario-driven process flow description capturemethod that represents:

• Process Flow Descriptions to capture the relationships between actions withinthe context of a specific scenario, and

• Object State Transition to capture the description of the allowable states andconditions.

This method is part of the IDEF family of modelling languages in the field ofsystems and software engineering. Additional information can be found via http://www.idef.com/IDEF3.htm. 122, 164


http://www.iaoa.org/

http://www.idef.com/

http://www.idef.com/IDEF3.htm

http://www.idef.com/IDEF3.htm

Glossary 180

intended structure Adopted from [23], an intended structure is a set of structuresthat characterizes the semantics of an ontology’s terminology. They are specifiedwith respect to models of well-understood mathematical theories, such as partialordering, 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 L(T1), such that

1. π assigns to ∀ a formula π∀ of L(T2), in which at most the variable v1 occursfree, such that

T2 |= (∃v1)π∀2. π assigns to each n-place relation symbol P a formula πP of L(T2), in which

at most the variable v1, . . . , vn occur free.

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

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-logicalsymbols in the signature Σ(T ). 11

Mace4 A program that searches for finite models of first-order formulas and can be usedin conjunction with Prover9 to find a proof and counter-example. 16

non-conservative extension Adopted from [14], T2 is a non-conservative extension ofT1 iff T2 is an extension of T1 and there exists a sentence σ ∈ Σ(T1) where

T1 6|= σ and T2 |= σ

. 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 inengineering by supporting university students in their advanced studies, and en-couraging Canadian companies to participate and invest in postsecondary researchprojects. Additional information about NSERC can be accessed via their homepage: http://www.nserc-crsng.gc.ca. 125

http://www.iso.org/iso/home.html

http://www.nserc-crsng.gc.ca/NSERC-CRSNG/Index_eng.asp

Glossary 181

OntoIOp The Ontology Integration and Interoperability is a working item proposed inISO TC37/SC3 that is intended to support the specification of a formal languagefor enabling distributed knowledge representation in ontologies; as well, the intentis to achieve interoperability across ontologies, services and devices. Additionalinformation 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, whichincludes the entire Cyc ontology containing hundreds of thousands of terms, alongwith millions of taxonomic assertions relating the terms to each other. This versionof Cyc does not contain the complex rules available in Cyc. Additional informationabout 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 characterizedby 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 viahttp://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 areendurants involved in an occurrence, so the notion of participation is not consideredparthood. In DOLCE, participation is time-indexed in order to account for thevarieties of participation in time, such as temporary participation and constantparticipation. 29, 181

perdurant In the philosophical sense, perdurants are entities that exist over successivetemporal 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 thesuccessor of the Otter theorem prover. 9, 16, 33, 49, 56, 57, 165

PSL Adapted from [12], the Process Specification Language is a neutral, interchangelanguage 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 asentity-relationship diagrams and class diagrams, that is based upon the notion ofmaking statements about resources in the form of ‘subject-predicate-object’ ex-pressions known as ‘triples.’ The subject denotes the resource, and the predicatedenotes the traits/aspects of the resource and expresses a relationship between thesubject 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:

http://www.iso.org/iso/standards_development/technical_committees/list_of_iso_technical_committees/iso_technical_committee.htm?commid=48136

http://ontolog.cim3.net/cgi-bin/wiki.pl?OntoIOp

http://www.cyc.com/platform/opencyc

http://www.w3.org/TR/owl-ref/

Glossary 182

• T faithfully interprets each theory Ti, and

• T1 ∪ ... ∪ Tn faithfully interprets T

. 14

relative consistency proof Adopted from [15], within the Interactive MathematicalProof 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 theoryand any theory developed from another is a conservative extension of the originaltheory, all theories developed are consistent relative to the original foundationaltheory, thus all proofs generated are guaranteed to be consistent. 32

representation theorem In mathematics, a representation theorem is a theorem thatstates 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-ordertheories to define the CIMOSA terminologies using the PSL axioms. 4, 89

semantic heterogeneity Semantic heterogeneity occurs when software applications anddatabases used by the data providers ascribe disparate meanings to the same termsor 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 isdenoted by Σ(T ). It is the set of all constant symbols, function symbols, andrelation 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 fordatabases, able to retrieve and manipulate data stored in Resource DescriptionFramework 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 throughoutthe manufacturing life cycle. 69, 70, 164

TPTP The Thousands of Problems for Theorem Provers is a library of test problemsfor automated theorem proving (ATP) systems, and consists of: a comprehensivelibrary of the ATP test problems, a comprehensive list of references and information

http://www.cs.miami.edu/~tptp/

Glossary 183

for each problem, arbitrary size instances of generic problems, a utility to convertthe problems to existing ATP systems’ formats, general guidelines outlining therequirements for ATP system evaluation, and standards for input and output forATP 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 thereis an interpretation of T0 in T1, then there exists a set of sentences that axiomatizesthe 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 freevariables are x. 6, 10, 15, 16, 165

Turtle The Terse RDF Triple Language is a format for expressing data in the RDF datamodel that uses triples, each of which consists of a subject, a predicate, and anobject. Turtle groups three URIs to make a triple, and provides ways to abbreviateinformation by factoring out common portions of URIs. For example, to expressthat Mark Twain was the author of Huckleberry Finn, the triple would be writtenas: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 thefield of software engineering that is standardized in ISO/IEC 19501:2005. TheUnified Modelling Language includes a set of graphic notation techniques to createvisual models of object-oriented software-intensive systems. Additional informationabout UML can be found via http://www.uml.org/. 122, 164

unit declaration Adopted from [3], indicates the component modules required withspecifications of each of them. 176

unit term Adopted from [3], descriptions of how modules are to be combined within anarchitectural 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 includea collection of terms found in thesauri and dictionaries, as well as taxonomies anddatabase schemas [55, 31]. 5

XML The Extensible Markup Language is a markup language defines rules for encodingdocuments in a format that is both human-readable and machine-readable. It wasdesigned with the intent to emphasize simplicity, generality, and usability over theInternet [8]. It is a textual data format that used to represent arbitrary data

http://www.w3.org/TR/turtle/

http://www.uml.org/

Glossary 184

structures as well as documents. Additional information about the specificationsof 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 6= ”inf − ” ⊃(∃u (before(”inf¬”, u) ∧ before(u, t))))). (A.1.8)

(∀t (timepoint(t) ∧ t 6= ”inf + ” ⊃(∃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)


Tpsl core

Tduration TocctreeTsubactivity

Tatomic

Tcomplex

Tactocc

Tdisc state

Figure A.1: The core theories of the PSL Ontology, adapted from [22]. Solid lines indicateconservative 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.


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

Theory Predicate Description

Tpsl core activity(a) a is an activityactivity occurrence(o) o is an activity occurrence

object(x) x is an objectoccurrence of(o, a) o is an occurrence of a

beginof(o) the beginning timepoint of oendof(o) the ending timepoint of o

before(t1, t2) timepoint t1 precedes timepoint t2 onthe timeline

Tsubactivity subactivity(a1, a2) a1 is a subactivity of a2primitive(a) a is a minimal element of the subactiv-

ity orderingTatomic atomic(a) a is either primitive or a concurrent ac-

tivityconc(a1, a2) the activity that the concurrent com-

position of a1 and a2Tocctree legal(s) s is an element of a legal occurrence

initial(s) s is the root of an occurrence treeearlier(s1, s2) s1 precedes s2 in an occurrence tree

Tdiscstate holds(f, s) the fluent f is true immediately afterthe activity occurrence s

prior(f, s) the fluent f is true immediately beforethe activity occurrence s

Tcomplex min precedes(s1, s2, a) The atomic subactivity occurrence s1precedes the atomic subactivity s2 inan activity tree for a

root(s, a) the atomic subactivity occurrence s isthe root of an activity tree for a

Tactocc subactivity occurrence(o1, o2) o1 is a subactivity occurrence of o2root occ(o) the initial atomic subactivity occur-

rence of oleaf occ(s, o) s is the final atomic subactivity occur-

rence of oTduration 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 timedurations

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


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) ⊃ ∀t′ (P (t′, t) ⊃ P (x, y, t′)) (Ad18)

(PED(x) ∧ P (x, y, t)) ⊃ x ⊆S< y, t > (Ad19)

Constitution


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)


K(x, y, t) ⊃ (PRE(x, t) ∧ PRE(y, t)) (Ad26)

K(x, y, t) ≡ ∀t (P (t′, t) ⊃ K(x, y, t′)) (Ad27)

(K(x, y, t) ∧ PED(x)) ⊃ x ≈S< y, t > (Ad28)

(K(x, y, t) ∧ P (y′, y, t)) ⊃ ∃x′ (P (x′, x, t) ∧K(x′, y′, t)) (Ad29)


Links Between Categories

GK(NAPO,M) (Ad30)

GK(APO,NAPO) (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


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)


PC(x, y, t) ⊃ (PRE(x, t) ∧ PRE(y, t)) (Ad36)

PC(x, y, t) ≡ ∀t′ (P (t′, t) ⊃ PC(x, y, t′)) (Ad37)

Ground Properties

¬PC(x, x, t) (Td6)

PC(x, y, t) ⊃ ¬PC(y, x, t) (Td7)

Being Present


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

((PED(x) ∨ PQ(x)) ∧ PRE(x, t)) ⊃ ∃s (PRE(s, x, t)) (Td16)


Ground Axioms

(PRE(x, t) ∧ P (t′, t)) ⊃ PRE(x, t′) (Td17)

PRE(s, x, t) ⊃ PRE(x, t) (Td18)

B.2 Additional DOLCE Axioms

B.2.1 Axiomatization of Tdolce 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

( c l−comment ”Root occur r ence s in the a c t i v i t y t r e e correspond toatomic s u b a c t i v i t y

occur r ence s o f the a c t i v i t y . ” )

( f o r a l l ( a s )( i f ( root s a )

( e x i s t s ( a1 )( and ( s u b a c t i v i t y a1 a )

( atocc s a1 ) ) ) ) )

Leaf Nodes in Occurrence Trees

( c l−comment ”An occur rence i s the l e a f o f an a c t i v i t y t r e e i fand only i f the re e x i s t s an e a r l i e r

atomic s u b a c t i v i t y occur rence but the re does not e x i s t a l a t e ratomic

s u b a c t i v i t y occur rence . ” )

193

http://code.google.com/p/colore/source/browse/trunk/ontologies/complex/process_specification_language/complex/complex.clif

Appendix C. Additional CIMOSA Information 194

( f o r a l l ( s a ) ( i f f ( l e a f s a )( and ( or ( root s a )

( min precedes s1 s a ) )( not ( e x i s t s ( s2 )

( min precedes s s2 a ) ) ) ) ) )

Precedence in Occurrence Trees

( c l−comment ” Act i v i t y t r e e s are sub t r e e s o f the occur rence t r e e .” )

( f o r a l l ( s1 s2 a )( i f ( min precedes s1 s2 a )

( precedes s1 s2 ) ) )

C.2 Common Logic Version of the CIMOSA Ontol-

ogy

( c l−t ex t cimosa

( c l−comment ” Sources : ISO 19439 :2006 , ISO 19440 :2007 ,Vernadat1998 . ” )

( c l−comment ”Comment : The f o l l o w i n g onto logy i s c r ea ted tod e s c r i b e the behav ioura l r u l e s e t found in CIMOSA. ” )

( c l−comment ” Import the PSL Core onto logy s i n c e the CIMOSAonto logy uses PSL c o n s t r u c t s . ” )

( c l−imports ps l−core )

( c l−comment ” Import the complex subtheory o f the PSL onto logys i n c e the CIMOSA onto logy uses PSL c o n s t r u c t s . ” )

( c l−imports complex )

( c l−comment ”===== Mappings =====” )( c l−comment ”Map between CIMOSA and PSL c o n s t r u c t s . ” )( c l−comment ”A bus ine s s p roce s s in CIMOSA i s an a c t i v i t y in PSL .

” )( f o r a l l ( x )

( i f ( b u s i n e s s p r o c e s s x ) ( a c t i v i t y x ) ) )


( c l−comment ”An e n t e r p r i s e a c t i v i t y in CIMOSA i s an a c t i v i t y inPSL . ” )

( f o r a l l ( x )( i f ( e n t e r p r i s e a c t i v i t y x ) ( a c t i v i t y x ) ) )

( c l−comment ”An e n t e r p r i s e func t i on in CIMOSA i s an a c t i v i t y inPSL . ” )

( f o r a l l ( x )( i f ( e n t e r p r i s e f u n c t i o n x ) ( a c t i v i t y x ) ) )

( c l−comment ”An e n t e r p r i s e ob j e c t in CIMOSA i s an ob j e c t in PSL .” )

( f o r a l l ( x )( i f ( e n t e r p r i s e o b j e c t x ) ( ob j e c t x ) ) )

( c l−comment ”An event in CIMOSA i s an a c t i v i t y in PSL . ” )( f o r a l l ( x )

( i f ( event x ) ( a c t i v i t y x ) ) )

( c l−comment ”An occur rence in CIMOSA i s an a c t i v i t y occur rencein PSL . ” )

( f o r a l l ( x )( i f ( occur rence x ) ( a c t i v i t y o c c u r r e n c e x ) ) )

( c l−comment ” Al l e n t e r p r i s e f u n c t i o n s are bus in e s s p r o c e s s e s ore n t e r p r i s e a c t i v i t i e s . ” )

( f o r a l l ( x )( i f ( e n t e r p r i s e f u n c t i o n x )

( or ( b u s i n e s s p r o c e s s x ) ( e n t e r p r i s e a c t i v i t y x ) )) )

( c l−comment ”===== Behavioura l Rule Set =====” )( c l−comment ”Ending Status (ES) Values ” )( c l−comment ” e n d s t a t 1 i s a constant / value ” )( f o r a l l ( o x )

( i f ( o c c u r r e n c e o f o ( e n t e r p r i s e f u n c t i o n x ) )( ho lds e n d s t a t 1 o ) ) )

( c l−comment ” Process Tr igge r ing Rules ” )( c l−comment ”WHEN (START WITH event−i AND event−j ) DO EF1” )( f o r a l l ( o1 o2 x f )

( i f ( and ( o c c u r r e n c e o f o1 ( domain process x ) )( root o2 o1 ) ( o c c u r r e n c e o f o2 (

e n t e r p r i s e f u n c t i o n f ) ) )


( e x i s t s ( o3 o4 i j )( and ( precedes o3 o2 ) ( precedes

o4 o2 )( o c c u r r e n c e o f o3 (

a c t i v i t y i ) ) (o c c u r r e n c e o f o4 (a c t i v i t y j ) ) ) ) ) )

( c l−comment ”WHEN (START) DO EF1” )( c l−comment ”OR f o r a l l bu s in e s s p roce s s e s , the re e x i s t a parent

p roce s s − i m p l i c i t that o precedes o1 because o f root ” )( f o r a l l ( o1 x )

( i f ( o c c u r r e n c e o f o1 ( b u s i n e s s p r o c e s s x ) )( e x i s t s ( o y )

( and ( root o o1 ) ( o c c u r r e n c e o f o (bus in e s s p roce s s y ) ) ( precedes o o1 ) ) )) )

( c l−comment ”Forced Sequent i a l Rules ” )( c l−comment ”WHEN (ES(EFx) = ANY) DO EFy” )( c l−comment ”Note : ANY i s a r e s e rved key word . ” )( f o r a l l ( o1 x )

( i f ( and ( ho lds ”ANY” o1 )( o c c u r r e n c e o f o1 ( e n t e r p r i s e f u n c t i o n x ) ) )( e x i s t s ( o2 y )

( and ( o c c u r r e n c e 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 ) ) ) ) )

( c l−comment ” Condi t iona l Sequent i a l Rules ” )( c l−comment ”WHEN (ES(EF1) = e n d s t a t 1 ) DO EF2” )( c l−comment ” I f the e n t e r p r i s e func t i on x has an ending s t a tu s

va lue o f end s ta t 1 , and o1 i s an occur rence o f x , then the ree x i s t s an o2 which i s an occur rence o f e n t e r p r i s e func t i on ythat occurs a f t e r o1 . ” )

( c l−comment ” end s ta t 1 , end s ta t 2 , e t c . are va lue s . ” )( f o r a l l ( o1 x )

( i f ( and ( ho lds e n d s t a t 1 o1 )( o c c u r r e n c e o f o1 ( e n t e r p r i s e f u n c t i o n x ) ) )( e x i s t s ( o2 y )


( precedes o1 o2 ) ) ) ) )


( c l−comment ”WHEN (ES(EF1) = e n d s t a t 2 ) DO EF3” )( f o r a l l ( o2 x )



( precedes o2 o3 ) ) ) ) )

( c l−comment ”WHEN (ES(EF1) = e n d s t a t 3 ) DO EF4” )( f o r a l l ( o3 x )



( precedes o3 o4 ) ) ) ) )

( c l−comment ”Spawning Rules ” )( c l−comment ”Asynchronous Spawning” )( c l−comment ”WHEN (ES(EF1) = value ) DO EF2 & EF3 & EF4” )( c l−comment ” value i s a s p e c i f i c ending s t a t u s . We do not know

in which order EF2 , EF3 , and EF4 occurs . ” )( f o r a l l ( o1 x )

( i f ( and ( ho lds va lue o1 )( o c c u r r e n c e o f o1 ( e n t e r p r i s e f u n c t i o n x ) ) )( e x i s t s ( o2 o3 o4 t y z )

( and ( o c c u r r e n c e o f o2 (e n t e r p r i s e f u n c t i o n t ) )

( o c c u r r e n c e o f o3 (e n t e r p r i s e f u n c t i o n y ) )

( o c c u r r e n c e o f o4 (e n t e r p r i s e f u n c t i o n z ) )

( precedes o1 o2 )( precedes o1 o3 )( precedes o1 o4 ) ) ) ) )

( c l−comment ”Synchronous Spawning” )( c l−comment ”WHEN (ES(EF1) = value ) DO SYNC (EF2 & EF3 & EF4) ” )( c l−comment ”Note : EF2 , EF3 and EF4 s t a r t at the same time po int

. ” )( f o r a l l ( o1 x )






( precedes o1 o2 )( precedes o1 o3 )( precedes o1 o4 )(= ( beg ino f o2 ) ( beg ino f o3 ) )(= ( beg ino f o2 ) ( beg ino f o4 ) ) ) ) )

)

( c l−comment ”Rendez−vous Rules ” )( c l−comment ”WHEN (ES(EF2) = va lue 2 AND ES(EF3) = va lue 3 AND

ES(EF4) = va lue 4 ) DO EF5” )( f o r a l l ( o2 o3 o4 x y z )

( i f ( and( ho lds va lue 2 o2 ) ( ho lds va lue 3 o3 ) (

ho lds va lue 4 o4 )( o c c u r r e n c e o f o2 ( e n t e r p r i s e f u n c t i o n x

) )( o c c u r r e n c e o f o3 ( e n t e r p r i s e f u n c t i o n y

) )( o c c u r r e n c e o f o4 ( e n t e r p r i s e f u n c t i o n z

) ) )( e x i s t s ( o5 t )



( c l−comment ”Loop Rules ” )( c l−comment ”WHEN (ES(EF1) = loop va lue ) DO EF1” )( f o r a l l ( o1 x )

( i f ( and ( ho lds l oop va lue o1 )( o c c u r r e n c e o f o1 ( e n t e r p r i s e f u n c t i o n x ) ) )( o c c u r r e n c e o f o1 ( e n t e r p r i s e f u n c t i o n x ) ) ) )

( c l−comment ” Process Completion Rules ” )( c l−comment ”WHEN (ES(EF1) = end s ta t x AND ES(EF2) = end s ta t y

) DO FINISH” )( c l−comment ” use l e a f node to r ep r e s e n t the end o f a p roce s s /

occur rence t r e e ” )


( c l−comment ” i f EF( f ) i s l e a f node , then i t must mean EF1 andEF2 reached t h e i r s p e c i f i c end s t a t e s o3 and o4 , r e s p e c t i v e l y” . . . ? )

( f o r a l l ( s a o1 o2 f )( i f ( and ( l e a f o c c o2 o1 )

( o c c u r r e n c e o f o2 ( e n t e r p r i s e f u n c t i o n f) ) )

( e x i s t s ( o3 o4 g i j )( and ( precedes o3 o2 ) ( precedes

o4 o2 )( o c c u r r e n c e o f o3 (

e n t e r p r i s e f u n c t i o n f) ) ( o c c u r r e n c e o f o4 (e n t e r p r i s e f u n c t i o n g) )

( ho lds end s ta t x o3 ) (ho lds end s ta t x o4 ) )) ) )

( c l−comment ”Run−Time Choice Rules ” )( c l−comment ”WHEN (ES(EF1) = e n d s t a t 1 ) DO S = (EF2 XOR EF3 XOR

EF4) ” )( c l−comment ” use d i s j u n c t i v e c l a u s e s to model XOR” )( c l−comment ”XOR i s de f ined as (p xor q = (p ˆ not q ) v ( not p ˆ

q ) ) ” )( c l−comment ” f o r s i m p l i c i t y ’ s sake , we assume there i s an

a l t e r n a t i v e between TWO d i f f e r e n t e n t e r p r i s e f u n c t i o n s ” )( f o r a l l ( o1 x )

( i f ( and ( ho lds e n d s t a t 1 o1 )( o c c u r r e n c e o f o1 ( e n t e r p r i s e f u n c t i o n x ) ) )( e x i s t s ( o2 o3 y )

( or( and

( and ( o c c u r r e n c e 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 ( o c c u r r e n c e o fo3 (

e n t e r p r i s e f u n c t i o n y) ) ( precedes o1 o3 ) ) ) )

( and( and ( o c c u r r e n c e 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 ) )


( not ( and ( o c c u r r e n c e o fo2 (

e n t e r p r i s e f u n c t i o n y) ) ( precedes o1 o2 ) ) ) )) ) ) )

( c l−comment ”Unordered Set Rules ” )( c l−comment ”WHEN (ES(EF1) = e n d s t a t 1 ) DO S = {EF2 , EF3 , EF4}”

)( c l−comment ” s e t o f execut ion i s unknown − AND − a l l EF need to

be repeated at l e a s t once ” )( f o r a l l ( o1 x )






)

Appendix D

Additional HomeServices

Information

D.1 Sample Item XML Result from Amazon

<Item><ASIN>B0002TXNX0</ASIN><DetailPageURL>ht tp : //www. amazon . com/Black−Decker−9099KC−7−2−Volt−Cord le s s /dp

/B0002TXNX0%3FSubscr ipt ionId%3DAKIAJHNOF4OERYF3SWSQ%26tag%3Dserv07−20%26l inkCode%3Dxm2%26camp%3D2025%26 c r e a t i v e%3D165953%26creativeASIN%3DB0002TXNX0</DetailPageURL>

<I temAttr ibutes><Binding>Tools &amp ; Home Improvement</ Binding><Brand>Black &amp ; Decker</Brand><CatalogNumberList><CatalogNumberListElement>9099KC</CatalogNumberListElement

><CatalogNumberListElement>315273</CatalogNumberListElement

></CatalogNumberList><EAN>0028877326764</EAN><EANList><EANListElement>0028877326764</EANListElement></

EANList><Feature>Balanced mid−handle des ign i n c r e a s e s the o v e r a l lcomfort o f the d r i l l and the user ’ s c o n t r o l when us ing thed r i l l </Feature>

201

Appendix D. Additional HomeServices Information 202

<Feature>Fan coo l ed motor c o n t r i b u t e s to a l onge r l i f e o fthe

d r i l l </Feature><Feature>Keyless chuck f o r quick and easy b i t changes</

Feature><Feature>2 speeds switch with forward / r e v e r s e − Low f o r

c o n t r o lwhen sc r ewdr iv ing ; high f o r d r i l l i n g </Feature><Feature>I n c l u d e s : 7.2−Volt d r i l l with i n t e g r a l bat te ry andk e y l e s s chuck and charger</Feature><ItemDimensions><Height Units=”hundredths−i n che s ”>300</Height><Length Units=”hundredths−i n che s ”>910</Length><Weight Units=”pounds”>3</Weight><Width Units=”hundredths−i n che s ”>890</Width>

</ItemDimensions><Label>Black &amp ; Decker</Label><Li s tPr i c e><Amount>4028</Amount><CurrencyCode>USD</CurrencyCode><FormattedPrice >$40.28</ FormattedPrice>

</L i s tPr i c e><Manufacturer>Black &amp ; Decker</Manufacturer><Model>9099KC</Model> <MPN>9099KC</MPN><PackageDimensions><Height Units=”hundredths−i n che s ”>300</Height><Length Units=”hundredths−i n che s ”>910</Length><Weight Units=”hundredths−pounds”>305</Weight><Width Units=”hundredths−i n che s ”>890</Width>

</PackageDimensions><PackageQuantity>1</PackageQuantity><PartNumber>9099KC</PartNumber><ProductGroup>Home Improvement</ProductGroup><ProductTypeName>TOOLS</ProductTypeName><Publ i sher>Black &amp ; Decker</Publ i sher><SKU>EMY−5148839</SKU><Studio>Black &amp ; Decker</Studio><Tit l e>Black &amp ; Decker 9099KC 7.2−Volt Cord le s s D r i l l

withKeyless Chuck</Ti t l e><UPC>028877326764</UPC><UPCList><UPCListElement>028877326764</UPCListElement></

UPCList><Warranty>2 year Warranty</Warranty>

</ItemAttr ibutes>


<OfferSummary><LowestNewPrice><Amount>2270</Amount><CurrencyCode>USD</CurrencyCode><FormattedPrice >$22.70</ FormattedPrice>

</LowestNewPrice><LowestUsedPrice><Amount>1969</Amount><CurrencyCode>USD</CurrencyCode><FormattedPrice >$19.69</ FormattedPrice>

</LowestUsedPrice><TotalNew>21</TotalNew><TotalUsed>9</TotalUsed><T o t a l C o l l e c t i b l e >0</T o t a l C o l l e c t i b l e><TotalRefurbished>0</TotalRefurbished>

</OfferSummary><Offer s><Tota lOf fe r s>2</Tota lOf fe r s><TotalOfferPages>1</TotalOfferPages><MoreOffersUrl>ht tp : //www. amazon . com/gp/ o f f e r− l i s t i n g /B0002TXNX0%3

FSubscr ipt ionId%3DAKIAJHNOF4OERYF3SWSQ%26tag%3Dserv07−20%26l inkCode%3Dxm2%26camp%3D2025%26 c r e a t i v e%3D386001%26creativeASIN%3DB0002TXNX0</MoreOffersUrl>

<Offer><Of f e rAt t r ibute s><Condition>New</Condition></

Of f e rAt t r ibute s><O f f e r L i s t i n g><O f f e r L i s t i n g I d>4JTBFiR1gdxwdpzRIuosYP68Tw6jz0ds%2

F65G6plTWXSSGFyOFdNdBHZiCVWMC5qLFwwKHjpHl9g9idyEQCPz9CSGY60Xg7RS1%2

BwYCCotii6fZrRLqL98ug%3D%3D</O f f e r L i s t i n g I d><Price><Amount>2270</Amount><CurrencyCode>USD</CurrencyCode><FormattedPrice >$22.70</ FormattedPrice>

</Price><AmountSaved><Amount>1758</Amount><CurrencyCode>USD</CurrencyCode><FormattedPrice >$17.58</ FormattedPrice>

</AmountSaved><PercentageSaved>44</PercentageSaved>


<A v a i l a b i l i t y>Usual ly sh ip s in 24 hours</A v a i l a b i l i t y><A v a i l a b i l i t y A t t r i b u t e s><Avai lab i l i tyType>now</Ava i lab i l i tyType><MinimumHours>0</MinimumHours><MaximumHours>0</MaximumHours>

</A v a i l a b i l i t y A t t r i b u t e s><I sE l i g ib l eForSuperSaverSh ipp ing>1</ I sE l i g ib l eForSuperSaverSh ipp ing>

</O f f e r L i s t i n g></Offer><Offer><Of f e rAt t r ibute s><Condition>Used</Condition>

</Of f e rAt t r ibute s><O f f e r L i s t i n g><O f f e r L i s t i n g I d>S51qO27ut2KczOkvKuUcnj0RVg2GlhO1jQGkhnfy6UX0EvRdCtWV%2Bf85SftDPZZj%2FO1AP47fxSGHXoN67%2FKnVrc2AeN9CKoW9grfJ9z6hTtrLIevhuVh95Xb4P5BdeWOl7xbRWe0Nry%2BD3qtkJeMecZf0Yy5Xnrx</O f f e r L i s t i n g I d><Price><Amount>1969</Amount><CurrencyCode>USD</CurrencyCode><FormattedPrice >$19.69</ FormattedPrice>

</Price><AmountSaved><Amount>2059</Amount><CurrencyCode>USD</CurrencyCode><FormattedPrice >$20.59</ FormattedPrice></AmountSaved>

<PercentageSaved>51</PercentageSaved><A v a i l a b i l i t y>Usual ly sh ip s in 1−2 bus in e s s days</

A v a i l a b i l i t y><A v a i l a b i l i t y A t t r i b u t e s><Avai lab i l i tyType>now</Ava i lab i l i tyType><MinimumHours>24</MinimumHours><MaximumHours>48</MaximumHours>

</A v a i l a b i l i t y A t t r i b u t e s><I sE l i g ib l eForSuperSaverSh ipp ing>0</ I sE l i g ib l eForSuperSaverSh ipp ing>

</O f f e r L i s t i n g></Offer>

</Of fe r s></Item>


D.2 Sample Item XML Result from Sears

<?xml version=” 1 .0 ” encoding=”UTF−8”?><ProductDeta i l><SoftHardProductDeta i l s><PartNumber>SPM609745014</PartNumber><MfgPartNumber>< ! [CDATA[ e 63q f s l ky1 ] ]></MfgPartNumber><VendorId>MKT</VendorId><MapIndicator /><MapPriceDescr ipt ion /><MapPriceValidDate/><SaveStory>< ! [CDATA[<div c l a s s ="youPay bl"><span c l a s s

=" p r i c i n g " itemprop=" p r i c e "> $128.27</span></div> ] ]></ SaveStory>

<BrandName>< ! [CDATA[ Black & Decker ] ]></BrandName><DescriptionName>< ! [CDATA[ Black & Decker LDX120C 20−Volt MAX

Lithium−Ion D r i l l / Dr iver

] ]></ DescriptionName><KsnValue/><MainImageUrl>< ! [CDATA[ h t tp : // c . sh ld . net / rpx/ i / s / p i /mp2/27946/

aHR0cDovL2ltZy5yZXZlcnNlZGUuY29tL2ltYWdlcy9JLzUxaVVHaTYyNFpMLmpwZw==?s r c=http%3A%2F%2Fimg . r eve r s ede . com%2

Fimages%2FI%2F51iUGi624ZL . jpg&d=c65d296925e933c276cd92e12f02159f3701da04 ] ]></MainImageUrl><Store Id>10153</ Store Id><CatalogId>12605</ CatalogId><Se l l e rCount>0</ Se l l e rCount><InStock>1</ InStock><WebStatus>1</WebStatus><LangId/><ProductVariant>< ! [CDATA[NONVARIATION] ]></ ProductVariant><S t o r e p i c k u p e l i g i b l e>0</ S t o r e p i c k u p e l i g i b l e><SRESEligible>0</ SRESEligible><StsType/><RelatedUrl /><F r e e S h i p p i n g E l i g i b l e> f a l s e</ F r e e S h i p p i n g E l i g i b l e> <S p e c i a l O f f e r

> f a l s e</ S p e c i a l O f f e r><ZeroFinance /><SkuDif f /><FitmentRequired /><Swatches/><Rating /><NumReview>0</NumReview><CatEntryId>1749892778</CatEntryId><ViewOnly> f a l s e</ViewOnly><ClickToTalk>< ! [CDATA[ f a l s e ] ]></ ClickToTalk>


<MailInRebate>0</ MailInRebate><OnlineOnlyPrice>0</ Onl ineOnlyPrice><Sa l ePr i c e>128 .27</ Sa l ePr i c e><RegularPr ice>128 .27</ RegularPr ice><AutomotiveDivis ion> f a l s e</ AutomotiveDivis ion><OptionTab> f a l s e</OptionTab><IsFrequencyModel /><MappedPriceIndicator /><MaintenanceAgreement/

><ProductProtect ionPlan /><I n s t a l l a t i o n K i t /><Connection /><Accessory /><SmartPlan/><GiftWrap/><HaulAway/><ProductVariants /><Shor tDesc r ip t i on>< ! [CDATA[<ul><l i >Lithium Ion Technology:

Lighter , more compact , no memory , l onge r l i f e </ l i ><l i >20V MaxLithium Ion Bat te ry : Holds charge l onge r between use and

has l onge r c y c l e l i f e </ l i ><l i >11 Pos i t i on Clutch : Providesp r e c i s e c o n t r o l f o r d r i l l i n g in to wood , metal , p l a s t i c , anda l l s c r ewdr iv ing tasks</ l i ><l i >Compact and L ightwe ight : Lessf a t i g u e and a l l ows us e r s to d r i l l / screw in con f ined spaces</ l i ><l i >Var iab le Speed: Allows counte r s i nk ing withoutdamaging mater ia l</ l i ></ul> ] ]></ Shor tDesc r ip t i on>

<LongDescr ipt ion>< ! [CDATA[ The Black &amp ; Decker LBXR20 20 VoltMAX Extended Run Time Lithium Battery i s compatible with the20−Volt MAX l i n e o f power and gardening t o o l s . Theseb a t t e r i e s have been formulated f o r l onge r runtime andimproved performance . This bat te ry i s compatible withc o r d l e s s t o o l models BDC120VA100 , BDCDMT120, BDCDMT120−2,BDCDMT120F, BDCDMT120IA, BDCF20, BDH2000SL , LD3K220 , LCC220 ,LCS120 , LCS120B , LD120VA, LDX120C, LDX120PK, LDX120SB ,LDX220SB , LDX220SBFC, LGC120 , GLC120B, LHT210 , LHT2220 ,LHT2220B , LLP120 , LLP120B , LPHT120 , LPHT120B, LPP120 , LPP120B, LST220 , LSW120 , LSW20, LSW20B, SSL20SB , SSL20SB−2. ] ]></LongDescr ipt ion>

<GroupDescr ipt ion /><SkuList><Sku><CatEntryId>1749892778</CatEntryId></Sku></ SkuList><ArrivalMethods><ArrivalMethod>Ship</ ArrivalMethod></ ArrivalMethods><PreSe l l Ind>No</ PreSe l l Ind><Fol lowItFlag>t rue</ Fo l lowItFlag><LMPStoreDetails><Time><TimeX/><TimeY/><TimeZ/></Time>


<OrderCutOffTime/><TomorrowHolidayFlag/><TodayHolidayFlag/><LDFlag/><StandardTimeZone/><PrepTime/><StoreUnitNumber/><OnHandQuantity/><SPU/><Mai lab le /><SRES/><WeekDayOpenTime/><WeekDayCloseTime/><SatOpenTime/><SatCloseTime/><SunOpenTime/><SunCloseTime/><LMPstock/><GetItNow/><RespFfm/><LeadTime/><StoreZipCode /></ LMPStoreDetails><PickUpOption>0</PickUpOption><Dis t r ibut i onCente r>VD</ Di s t r ibu t i onCente r><CheckOutEnable>t rue</CheckOutEnable><IsKMartSPU> f a l s e</IsKMartSPU><Variant>NONVARIATION</ Variant><RegAvlMainFlag> f a l s e</RegAvlMainFlag><ExpressCheckOutEl ig ib le>Y</ ExpressCheckOutEl ig ib le><Mobi leExpressCheckOutEl ig ib le>Y</ Mobi leExpressCheckOutEl ig ib le><SoldBy>< ! [CDATA[ OnlineWholeSale ] ]></SoldBy><OtherFBMMerchants/><OtherCPCMerchants/></ SoftHardProductDeta i l s><StatusData><ResponseCode>0</ResponseCode><RespMessage>The ac t i on i s s u c c e s s f u l</RespMessage></ StatusData><ApiTracking>S e r v e r : PROD−SERVER−404−2|Tracking ID:{1366120886491}|API Cl i en t Se s s i on Key: n u l l |Time : Tue Apr16 09 : 0 1 : 2 6 CDT 2013 |UID : 5089853257140110922 |From Cache : Y</ ApiTracking>

</ ProductDeta i l>

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.


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/

ht tp : // webse rv i c e s . amazon . com/onca/xml? Se r v i c e=AWSECommerceService&Operation=ItemLookup&Subsc r ip t i on Id=AKIAJHNOF4OERYF3SWSQ&AssociateTag=serv07−20&Vers ion=2011−08−01&ItemId=B004443WVW&IdType=ASIN&Condit ion=New&ResponseGroup=Images , I temAttr ibutes , Of f e r s , Acce s so r i e s ,A l te rnateVers ions , BrowseNodes , Editor ia lReview , Of f e rFu l l ,OfferSummary , Reviews , SalesRank , S i m i l a r i t i e s , Tracks ,Variat ionImages , Variat ionMatr ix , VariationSummary ,Var i a t i on s

• Sears:http://www.sears.com/black-decker-12-v-max-lithium-drill-driver/p-00930268000P

c u r l ” h t tp : // api . deve loper . s e a r s . com/v1/ p r o d u c t d e t a i l s ?apikey=0ea2982977bb5217b3973bd2c315be39&s t o r e=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:

http://www.amazon.com/dp/B004443WVW/

http://www.sears.com/black-decker-12-v-max-lithium-drill-driver/p-00930268000P

http://www.sears.com/black-decker-12-v-max-lithium-drill-driver/p-00930268000P


• Amazon: http://www.amazon.com/dp/B0008IVWVU

ht tp : // webse rv i c e s . amazon . com/onca/xml? Se r v i c e=AWSECommerceService&Operation=ItemLookup&Subsc r ip t i on Id=AKIAJHNOF4OERYF3SWSQ&AssociateTag=serv07−20&Vers ion=2011−08−01&ItemId=B0008IVWVU&IdType=ASIN&Condit ion=New&ResponseGroup=Images , I temAttr ibutes , Of f e r s , Acce s so r i e s ,A l te rnateVers ions , BrowseNodes , Editor ia lReview , Of f e rFu l l ,OfferSummary , Reviews , SalesRank , S i m i l a r i t i e s , Tracks ,Variat ionImages , Variat ionMatr ix , VariationSummary ,Var i a t i on s

• Sears:http://www.sears.com/tajima-tool-corp-rapid-pull-265-15-tpi/p-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

ht tp : // webse rv i c e s . amazon . com/onca/xml? Se r v i c e=AWSECommerceService&Operation=ItemLookup&Subsc r ip t i on Id=AKIAJHNOF4OERYF3SWSQ&AssociateTag=serv07−20&Vers ion=2011−08−01&ItemId=B001O8QSTY&IdType=ASIN&Condit ion=New&ResponseGroup=Images , I temAttr ibutes , Of f e r s , Acce s so r i e s ,A l te rnateVers ions , BrowseNodes , Editor ia lReview , Of f e rFu l l ,OfferSummary , Reviews , SalesRank , S i m i l a r i t i e s , Tracks ,Variat ionImages , Variat ionMatr ix , VariationSummary ,Var i a t i on s

• Sears:http://www.sears.com/craftsman-16-oz-rubber-mallet/p-00945787000P


http://www.amazon.com/dp/B0008IVWVU

http://www.sears.com/tajima-tool-corp-rapid-pull-265-15-tpi/p-00988400000P

http://www.sears.com/tajima-tool-corp-rapid-pull-265-15-tpi/p-00988400000P

http://www.amazon.com/dp/B001O8QSTY

http://www.sears.com/craftsman-16-oz-rubber-mallet/p-00945787000P


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

ht tp : // webse rv i c e s . amazon . com/onca/xml? Se r v i c e=AWSECommerceService&Operation=ItemLookup&Subsc r ip t i on Id=AKIAJHNOF4OERYF3SWSQ&AssociateTag=serv07−20&Vers ion=2011−08−01&ItemId=B006WKZVM4&IdType=ASIN&Condit ion=New&ResponseGroup=Images , I temAttr ibutes , Of f e r s , Acce s so r i e s ,A l te rnateVers ions , BrowseNodes , Editor ia lReview , Of f e rFu l l ,OfferSummary , Reviews , SalesRank , S i m i l a r i t i e s , Tracks ,Variat ionImages , Variat ionMatr ix , VariationSummary ,Var i a t i on s

• Sears:http://www.sears.com/delta-shower-arm-and-flange/p-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

ht tp : // webse rv i c e s . amazon . com/onca/xml? Se r v i c e=AWSECommerceService&Operation=ItemLookup&Subsc r ip t i on Id=AKIAJHNOF4OERYF3SWSQ&AssociateTag=serv07−20&Vers ion=2011−08−01&ItemId=B000I1L6QI&IdType=ASIN&Condit ion=New&ResponseGroup=Images , I temAttr ibutes , Of f e r s , Acce s so r i e s ,A l te rnateVers ions , BrowseNodes , Editor ia lReview , Of f e rFu l l ,OfferSummary , Reviews , SalesRank , S i m i l a r i t i e s , Tracks ,Variat ionImages , Variat ionMatr ix , VariationSummary ,Var i a t i on s

• Sears:http://www.sears.com/knipex-8inch-cable-shears-comfort-grip/p-00990571000P

http://www.amazon.com/dp/B006WKZVM4

http://www.sears.com/delta-shower-arm-and-flange/p-08319019000P

http://www.amazon.com/dp/B000I1L6QI

http://www.sears.com/knipex-8inch-cable-shears-comfort-grip/p-00990571000P

http://www.sears.com/knipex-8inch-cable-shears-comfort-grip/p-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 <link> 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].

< !DOCTYPE html PUBLIC ”−//W3C//DTD XHTML 1.1//EN” ” http ://www. w3. org /TR/xhtml11/DTD/xhtml11 . dtd”>

<html xmlns=” http ://www. w3 . org /1999/ xhtml” xml : lang=”en” lang=”en”>

<head prof i le=” http ://www. w3 . org /2003/g/data−view”><t i t l e>Robin ’ s Schedule</ t i t l e><l ink rel=” trans fo rmat ion ” href=” http ://www. w3 . org /2002/12/

c a l / glean−hca l ”/></head><body>. . .

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.

http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl

http://www.w3.org/2001/sw/grddl-wg/td/glean_title.xsl


<html xmlns=” http ://www. w3 . org /1999/ xhtml” xmlns : g rdd l =’http ://www. w3 . org /2003/g/data−view#’ grddl : t rans fo rmat ion=”g l e a n t i t l e . x s l http ://www. w3 . org /2001/sw/ grddl−wg/td/getAuthor . x s l ”

><head><t i t l e>Are You Experienced ?</ t i t l e>[ . . . ]</html>

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:

x s l t p r o c . exe xml2 rd f3 s ea r s . x s l s h e a r s s e a r s . xml > s h e a r s s e a r s .rd f

x s l t p r o c . exe xml2 rd f3 s ea r s . x s l shears amazon . xml >shears amazon . rd 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.

http://xmlsoft.org/XSLT/xsltproc2.html




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 STLBackdata store by uploading the following files:

• RDF triples:

– bd drill amazon.rdf

– bd drill sears.rdf

– flange amazon.rdf

– flange sears.rdf

– mallet amazon.rdf

– mallet sears.rdf

– sawblade amazon.rdf

– sawblade sears.rdf

– shears 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 Namespacestab.

3. In the repository Overview screen, materialize the triples by clicking on MaterializeEntailed 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.

http://www.franz.com/agraph/allegrograph/


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 akeyword.

• Table D.3 lists the average price of products (specified by keyword) offered by Searsand 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 basedon 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 fromDBPedia.


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 MaxLithium Drill/-Driver ”

”Black & DeckerLDX112C 12-VoltMax Lithium-Ion\r\nDrill/Driver”

”49.99” ”59.99”

Table D.4: Results of finding the average price of products and lists them according tomanufacturer 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 bothvendors and lists them according to manufacturer number.

mfgno searsavg amazonavg

”LDX112C” ”49.99” ”59.99”


Table D.6: Results of finding the combined product model, sorted by manufacturer partnumber. (Results are truncated due to limited page space.)

mfgno amazonTitle amazondescription searsTitle searsdescription searsdescription2

”GNB-265”

”TajimaGNB-26515 TPIRapid PullReplace-ment\r\nBlade”

”Fine cut3-timesfasterthan nor-mal\r\nblades”

”RapidPull 26515 TPIblade ”

:b7D9DF37Dx2199 ”15 TPI Fine-Cut blade, 1blade pack”

”LDX112C””Black &DeckerLDX112C12-VoltMaxLithium-Ion\r\nDrill/-Driver”

”Compactandlightweightfor lessuser fa-tigueand\r\nfor drillingand screw-driving inconfinedspaces”

”12 V MaxLithiumDrill/-Driver”

”Black &Decker 12 Vmax lithiumdrill/driver.Drilling throughwood, metal,and plastic. Byproviding extralevel of control,the 11 positionclutch preventsstripping andoverdrivingscrews.

”U4993-SS”

”DeltaFaucetU4993-SSUniversalShoweringCompo-nents\r\nShowerArm andFlange,Stainless”

”See whatDelta cando”

”ShowerArm AndFlange ”

:b7D9DF37Dx1908 ”Timelessdesign for to-day'shomes”


Table D.7: Results of the federated query. Note that the results are incorrect and thatthe brandDBPediaURI field is empty.

productBrand foundingYear searstitle amazontitle brandDBPediaURI

”Craftsman” ”2003” ”16 oz. RubberMallet”

”Craftsman 16oz. RubberMallet”

”Knipex” ”2003” ”8"Cable shears-comfort grip ”

”KNIPEX 9512 200 ComfortGrip CableShears”






















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:

<div xmlns=” http ://www. w3 . org /1999/ xhtml”xmlns : r d f=” http ://www. w3 . org /1999/02/22− rdf−syntax−ns#”xmlns : r d f s=” http ://www. w3 . org /2000/01/ rdf−schema#”xmlns : xsd=” http ://www. w3 . org /2001/XMLSchema#”xmlns : gr=” http :// pur l . org / g o o d r e l a t i o n s /v1#”xmlns : f o a f=” http :// xmlns . com/ f o a f /0 .1/ ”xmlns : pto=” http ://www. productonto logy . org / id /”><div typeo f=” gr : O f f e r i ng ” about=”#o f f e r i n g ”><div rev=” gr : o f f e r s ” r e s ou r c e=” http ://www. s e a r s . com/ shc / s /”>

</div><div property=” gr : name” content=”Ty Pennington Sty l e

Mayf ie ld 4 Pc . Deep Seat ing Set ” xml : lang=”en”></div><div property=” gr : d e s c r i p t i o n ” content=”The Mayf ie ld 4 Pc .

Deep Seat ing Set f o r Deep Soothing Moments” xml : lang=”en”></div>

<div property=” gr : e l i g i b l e R e g i o n s ” content=”US” datatype=”xsd : s t r i n g ”></div>

<div rel=” gr : h a s P r i c e S p e c i f i c a t i o n ”><div typeo f=” gr : U n i t P r i c e S p e c i f i c a t i o n ”><div property=” gr : hasCurrency ” content=”USD” datatype=”

xsd : s t r i n g ”></div><div property=” gr : hasCurrencyValue ” content=” 799.99000 ”

datatype=”xsd : f l o a t ”></div><div property=” gr : hasUnitOfMeasurement” content=”C62”

datatype=”xsd : s t r i n g ”></div></div>

</div><div rel=” gr : hasBus inessFunct ion ” r e sou r c e=” http :// pur l . org /

g o o d r e l a t i o n s /v1#S e l l ”></div>

Documents

by Carmen Chui - University of Toronto T-Space · chitecture (CIMOSA) framework by augmenting its constructs with terminology found in PSL. Finally, we attempt to map two semantically-weak