CAPTURING, SHARING, AND DISCOVERING PRODUCT DATA AT A

SEMANTIC LEVEL - MOVING FORWARD TO THE SEMANTIC WEB FOR

ADVANCING THE ENGINEERING PRODUCT DESIGN PROCESS

By

LIJUAN ZHU

A dissertation submitted in partial fulfillment of the requirements for the degree of

DOCTOR OF PHILOSOPHY

WASHINGTON STATE UNIVERSITY School of Mechanical and Materials Engineering

August 2011

© Copyright by LIJUAN ZHU, 2011 All Right Reserved

To the Faculty of Washington State University:

The members of the Committee appointed to examine the dissertation of LIJUAN

ZHU find it satisfactory and recommend that it be accepted.

______Uma Jayaram, Ph.D., Chair

______Sankar Jayaram, Ph.D.

______Hakan Gurocak, Ph.D.

ii

ACKNOWLEDGMENTS

I would like to give special thanks to my parents, their love and encouragement that enabled me to achieve my goals. Thanks to my friends and fellow members in

VRCIM Laboratory I’ve worked with: Okjoon, Vinay, Nathan, Panni and Pei. Finally, special and sincere thanks to my committee, Dr. Uma Jayaram, Dr. Sankar Jayaram, Dr.

Hakan Gurocak and Dr.Jitesh Panchal, whose mentoring, wisdom, and friendship have been gratefully received and I will be benefitted with them for all of my life.

iii

CAPTURING, SHARING, AND DISCOVERING PRODUCT DATA AT A

SEMANTIC LEVEL - MOVING FORWARD TO THE SEMANTIC WEB FOR

ADVANCING THE ENGINEERING PRODUCT DESIGN PROCESS

Abstract

By Lijuan Zhu, PhD Washington State University August 2011

Chair: Uma Jayaram

Along with the greater productivity that CAD automation provides nowadays, the product data of engineering applications needs to be shared and managed efficiently to gain a competitive edge for the engineering product design. However, exchanging and sharing the heterogeneous product data is still challenging. This dissertation first presents a detailed exploration on semantic strategies based on ontology models for integrating product data between multiple engineering applications, including two typical CAD applications in Product Design Domain, and one CAE application in Assembly

Simulation Domain. It is concluded that the semantic approach is superior for exchanging and sharing heterogeneous product data at a semantic level.

Further, this dissertation postulates an approach to introduce reasoning capability into the engineering ontologies in product assembly domain to truly exploit this logic- based and formal representation for product data. A layered architecture for semantic applications containing reasoning units is proposed. Retrieval specifications and inference rules in SWRL/SQWRL are defined in these reasoning units. It is concluded

iv

that the reasoning mechanism extends the semantic representation made possible through the ontology and holds promise for improving design knowledge understanding and discovery.

Finally, based on research achievements on ontology modeling and reasoning, this dissertation presents an online Product Design Semantic Knowledge Management

System (PD-SKMS) for presenting, querying/reasoning, and authoring/updating product data semantics by incorporating Semantic Web technologies. The Product Semantic

Repositories (PSR) in a Host Hybrid-Data Repository (HDR) preserves product data semantics for the product assembly domain. A Semantic Data Management Engine

(SDME) provides querying/reasoning and authoring/updating services on PSRs. By linking to public linked data, the capability of PD-SKMS is extended to external data sources. It is concluded that the PD-SKMS delivers an interactive and knowledge- contextual design environment for the engineers on the Web and it greatly improves the traditional behaviors for exchanging and sharing product design knowledge.

In summary, this dissertation proposes, discusses, and implements semantic approaches to support design activities for capturing, sharing, and discovering product data semantics in a knowledge-contextual environment. Several practical scenarios successfully demonstrate the proposed approaches and reveal the great potential of semantic approaches for advancing the traditional engineering product design process.

v

TABLE OF CONTENTS

ACKNOWLEDGMENTS ...... iii

ABSTRACT ...... iv

LIST OF TABLES ...... xiii

LIST OF FIGURES ...... xiv

CHAPTER ONE - INTRODUCTION ...... 1

CHAPTER TWO - PROBLEM STATEMENT, PROPOSED SOLUTION,

AND SCOPE OF WORK ...... 4

2.1 STATEMENT OF PROBLEM ...... 4

2.2 PROPOSED SOLUTION ...... 6

2.3 SCOPE OF RESEARCH ...... 6

2.4 OVERVIEW OF THE DISSERTATION ...... 8

CHAPTER THREE - SEMANTIC INTEGRATION OF CAD/CAE

APPLICATIONS BASED ON ONTOLOGY MODELING: STRATEGIES

AND COMPARISONS ...... 10

ABSTRACT ...... 10

1. INTRODUCTION AND MOTIVATION ...... 10

2. LITERATURE REVIEW AND BACKGROUND ...... 13

2.1 PRODUCT DATA REPRESENTATION FOR INTEGRATION FRAMEWORK OF ENGINEERING

APPLICATIONS ...... 13

2.2 CONVENTIONAL DATA TRANSFER APPROACHES ...... 14

vi

2.3 OVERVIEW OF ONTOLOGY MODELING FOR ENGINEERING DOMAINS ...... 15

3. RESEARCH OBJECTIVES ...... 17

4. ONTOLOGY MODELING FOR KNOWLEDGE REPRESENTATION .... 18

4.1 FUNDAMENTAL LAYERED STRUCTURE OF ENGINEERING ONTOLOGY ...... 19

4.1.1 Modeling of General Domain Ontology (GDO) ...... 20

4.1.2 Modeling of Domain Specific Ontology (DSO) ...... 21

4.1.3 Modeling of Application Specific Ontology (ASO) ...... 22

4.2 DISCUSSION ON LAYERED STRUCTURE OF ENGINEERING ONTOLOGY ...... 26

5. ONTOLOGY-DRIVEN STRATEGIES FOR INTEGRATION OF

CAD/CAE APPLICATIONS ...... 27

5.1 EXTRACT DATA FROM SOURCE CAD/CAE APPLICATION AND INSTANTIATE KNOWLEDGE LAYER

OF SOURCE ASO ...... 28

5.1.1 Test Case: Extract Product Data from PRO/E and Instantiate PRO-AO ...... 29

5.2 TRANSFER PRODUCT DATA SEMANTICS FROM SOURCE APPLICATION TO TARGET APPLICATIONS

...... 31

5.2.1 Test Case 1: Integrate CAD Applications (PRO/E and CATIA) within One Domain

(Product Design Domain) ...... 33

5.2.2 Test Case 2: Integrate Applications across Two Domains (PRO/E in Product Design

Domain and VADE Assembly Simulation Domain) ...... 39

5.3 DISCUSSION ON ONTOLOGY -DRIVEN STRATEGY FOR CAD/CAE INTEGRATION ...... 41

6. COMPARISON STUDIES BETWEEN ONTOLOGY AND OTHER

TECHNOLOGIES ...... 43

6.1 COMPARISON BETWEEN ONTOLOGY KNOWLEDGE MODELING AND UML MODELING ...... 43

6.2 COMPARISON BETWEEN ONTOLOGY -DRIVEN DATA TRANSFER APPROACH WITH TRADITIONAL

PRO /VADE ...... 45

vii

7. SUMMARY AND FUTURE WORK ...... 47

8. ACKNOWLEDGEMENTS ...... 48

GLOSSARY OF TERMS ...... 49

REFERENCE ...... 49

CHAPTER FOUR - SEMANTIC APPLICATIONS ENABLING REASONING

IN PRODUCT ASSEMBLY ONTOLOGIES - MOVING PAST MODELING ...... 55

ABSTRACT ...... 55

1. INTRODUCTION...... 55

2. LITERATURE REVIEW AND BACKGROUND ...... 57

2.1 CONVENTIONAL REASONING ON PRODUCT DATA ...... 57

2.2 ONTOLOGY REASONING ...... 59

2.3 ONTOLOGY REASONING APPLIED IN PRODUCT ENGINEERING ...... 60

3. ONTOLOGY REASONING ...... 62

3.1 OBJECTIVE ...... 62

3.2 SOME ONTOLOGY REASONING MECHANISMS , FACILITATORS AND HOW WE USE THEM ...... 63

4. DESIGNING THE UNDERLYING MODEL ...... 66

4.1 OVERALL SEMANTIC APPLICATION ARCHITECTURE ...... 66

4.2 REASONING UNITS IN LOGIC REASONING LAYER ...... 68

4.3 USER INTERFACE IN APPLICATION INTERFACE LAYER ...... 69

4.4 SEQUENCE OF REASONING ...... 70

5. DESIGN OF REASONING UNITS IN THE LOGIC REASONING

LAYER...... 71

viii

5.1 DESIGN OF REASONING UNITS FOR ASSEMBLY LEVEL ...... 71

5.2 DESIGN OF REASONING UNITS FOR COMPONENT LEVEL ...... 85

5.3 TABULATION OF REASONING UNITS ...... 88

6. SYNTHESIS OF REASONING UNITS IN ILLUSTRATIVE

EXAMPLES ...... 89

6.1 TEST CASE FOR ASSEMBLY LEVEL ...... 90

6.2 TEST CASE FOR COMPONENT LEVEL ...... 95

7. SIGNIFICANCE OF SEMANTIC APPLICATIONS IN ENHANCING

CAD FUNCTIONALITIES ...... 97

8. SUMMARY ...... 99

9. FUTURE WORK ...... 100

10. ACKNOWLEDGEMENTS ...... 101

APPENDIX ...... 101

GLOSSARY OF TERMS ...... 101

PROPERTIES OF ONTOLOGIES USED IN THIS PAPER ...... 101

REFERENCES ...... 102

CHAPTER FIVE - ONLINE SEMANTIC KNOWLEDGE MANAGEMENT

FOR PRODUCT DESIGN BASED ON PRODUCT ENGINEERING

ONTOLOGIES ...... 108

ABSTRACT ...... 108

INTRODUCTION...... 109

ix

LITERATURE REVIEW AND BACKGROUND ...... 110

SEMANTIC WEB AND PUBLIC LINKED DATA ...... 110

KNOWLEDGE -BASED SYSTEM FOR ENGINEERING DOMAIN ...... 111

ONLINE SEMANTIC TOOL FOR ENGINEERING DOMAIN ...... 113

OUR PREVIOUS WORK ...... 114

SEMANTIC WEB TECHNOLOGIES ...... 115

PRODUCT DESIGN SEMANTIC KNOWLEDGE MANAGEMENT

SYSTEM (PD-SKMS) ...... 117

REQUIREMENTS FOR PD-SKMS ...... 117

OBJECTIVES OF PD-SKMS ...... 119

UNDERLYING ARCHITECTURE OF PD-SKMS ...... 119

COMPONENTS DEPLOYED IN PD-SKMS ...... 121

HOST HYBRID -DATA REPOSITORY (HDR) ...... 121

Product Semantic Repository (PSR) ...... 121

Product database (PDB) ...... 123

INTEGRATION OF PSR AND PDB ...... 124

SEMANTIC DATA MANAGEMENT ENGINE (SDME) ...... 124

QUERYING /R EASONING ON PSR ...... 125

AUTHORING /U PDATING ON PSR ...... 129

SEARCHING AND UPDATING ON PDB ...... 131

VISUALIZE SEMANTIC DATA ...... 131

LINK TO EXTERNAL PUBLIC LINKED DATA (EPLD) ...... 133

DETAILED EXAMPLE OF PD-SKMS ...... 134

x

DESIGN TASK : HUBBLE TELESCOPE ...... 134

TOOLKITS ...... 136

SCENARIO 1: QUERY ON PSR AND PDB AND EXHIBIT PRODUCT DATA SEMANTICS ...... 137

SCENARIO 2: REASONING ON PSR ...... 138

SCENARIO 3: LINK TO PUBLIC LINKED DATA ...... 141

CONCLUSION ...... 142

FUTURE WORK ...... 142

ACKNOWLEDGEMENTS ...... 143

REFERENCE ...... 144

CHAPTER SIX - KNOWLEDGE REPRESENTATION AND

QUERYING/REASONING FOR PDM SYSTEM ...... 150

6.1 KNOWLEDGE REPRESENTATION AND INTEGRATION OF PDM

SYSTEM ...... 150

6.2 ONTOLOGY QUERYING AND REASONING ON PDM

ONTOLOGY ...... 155

CHAPTER SEVEN - SUMMARY AND FUTURE WORK ...... 159

7.1 SUMMARY ...... 159

7.1.1 SEMANTIC INTEGRATION OF CAD/CAE APPLICATIONS ...... 160

7.1.2 ONTOLOGY QUERYING AND REASONING ...... 160

7.1.3 ONLINE PRODUCT SEMANTIC DESIGN ENVIRONMENT ...... 161

7.1.4 KEY CONTRIBUTIONS ...... 162

7.2 FUTURE WORK ...... 163

xi

APPENDIX A – ACRONYMS ...... 167

APPENDIX B – RULES FOR ONTOLOGY QUERYING AND REASONING ... 168

APPENDIX C – CORE CODE FOR PRODUCT DATA INSTANTIATION ...... 174

APPENDIX D – TOOLKITS ADOPTED FOR DELIVERED APPLICATIONS . 187

xii

LIST OF TABLES

Table 3 - 1: Segment of Comparison on Assembly Constraint Definition between PRO/E,

CATIA and VADE ...... 32

Table 3 - 2 : Mapping Results of Concept/Property between PRO-AO and CAT-AO .... 37

Table 3 - 3: Instantiation of CAT-AO by Product Data Semantics in PRO-AO ...... 37

Table 3 - 4: Mapping Results of Concept/Property between PRO-AO and ...... 41

Table 3 - 5: Mapping between Ontology Properties and UML Association ...... 43

Table 4 - 1: Summary of Reasoning Units...... 89

Table 4 - 2: Summary of Query and Inference Results for Lens Truss ...... 94

Table 4 - 3: CAD System VS. Semantic Application ...... 99

Table 5 - 1: SPARQL Example for Product Design Domain ...... 117

Table 5 - 2 : Two Approaches to Access PSR ...... 122

Table 5 - 3: Structure of PDB ...... 123

Table 5 - 4: SPARQL Queries for a), b), c) & d) ...... 127

Table 5 - 5: Reasoning for e) ...... 128

Table 5 - 6: Reasoning for f) ...... 129

Table 5 - 7: Authoring/Updating on PSR ...... 130

Table 5 - 8: Searching and Updating on PDB...... 131

Table 5 - 9: JSON Data Inlined in Exhibit ...... 133

Table 5 - 10 : Toolkits Adopted by PD-SKMS...... 136

xiii

LIST OF FIGURES

Figure 3 - 1: Data Integration between Applications within/across Domains ...... 18

Figure 3 - 2: Relationship between Knowledge Layer and Instance Layer of Product Data

Semantics ...... 19

Figure 3 - 3: Structure and Deployment of 3-tier Ontologies ...... 20

Figure 3 - 4: Definition of Concepts in FBM-DO and ASM-DO ...... 21

Figure 3 - 5: Concept Definition of PRO-AO ...... 23

Figure 3 - 6: Property Definition of PRO-AO ...... 24

Figure 3 - 7: Restriction Definition for Insert ...... 25

Figure 3 - 8: Concepts Hierarchy in VADE-AO ...... 26

Figure 3 - 9: Extract and Instantiate Product Data Semantics for PRO-AO ...... 29

Figure 3 - 10: Engine Assembly Model in PRO/E ...... 30

Figure 3 - 11: Component Instantiation from Engine-Head Assembly Model ...... 30

Figure 3 - 12: Constraint Instance Example in PRO-AO ...... 31

Figure 3 - 13: Overall mapping procedure between ontologies ...... 35

Figure 3- 14: Parse Product Data Semantics from CAT-AO and Retrieve Product Data into CATIA ...... 38

Figure 3- 15: Product Data Semantics in VADE-AO ...... 40

Figure 3- 16: Ontology-Driven Strategy for Integration of Engineering Tools in

CAD/CAE Domain ...... 42

Figure 3- 17: Segments of UML Modeling for an Assembly Model in Pro/E ...... 44

Figure 3- 18: Segment of *.vade file ...... 46

xiv

Figure 4 - 1: Relation Definitions of Two Components in A CAD Ontology Coded in

OWL DL ...... 64

Figure 4 - 2: Semantic Application Architecture ...... 67

Figure 4 - 3: User Interface Designed for Semantic Applications ...... 70

Figure 4 - 4: Overall Sequence of Reasoning for Assembly and Component Levels ...... 71

Figure 4 - 5: Multiple Views of Component Hierarchy in Semantic Application ...... 73

Figure 4 - 6: A Simple Assembly Model and Constraint Details in PRO/E ...... 76

Figure 4 - 7: Multiple Views of Constraint Information in Semantic Application ...... 76

Figure 4 - 8: SWRL/SQWRL Rule Infers Relation between Constraints and Components

...... 79

Figure 4 - 9: A Simple Assembly Sequence Starting from PART_C ...... 81

Figure 4 - 10: Construction of Assembly Sequence by Inferences of SWRL Rule ...... 82

Figure 4 - 11: Iteration Process for Inferring Assembly Sequence ...... 82

Figure 4 - 12: Internal Relationships among PART_A, PART_B and PART_C ...... 84

Figure 4 - 13: Two Components (PART_B and PART_C) in PRO/E ...... 86

Figure 4 - 14: Example Assembly: Hubble Telescope ...... 91

Figure 4 - 15: Main User Interface of Semantic Application for Assembly Level...... 92

Figure 4 - 16: Composition Tree Constructed for Hubble Telescope Assembly ...... 93

Figure 4 - 17: Query and Inference Results about Design Context of Lens Truss ...... 94

Figure 4 - 18: Example of an Assembly Sequence for Optical System of Hubble

Telescope ...... 95

Figure 4 - 19: Ontology-Driven User Interface of Semantic Application for Component

Level ...... 96

xv

Figure 5 - 1: Semantic Web Stack (Wikipedia, 2010) ...... 116

Figure 5 - 2: Design Process Yields Requirements for PD-SKMS ...... 118

Figure 5- 3: Underlying Architecture of PD-SKMS ...... 120

Figure 5 - 4: Organization of Product Semantic Repository ...... 123

Figure 5 - 5 : Functionality of SDME ...... 125

Figure 5 - 6: Visualization for Query/Reasoning Results from SDME (incomplete) ..... 132

Figure 5 - 7 : Visualization for Retrievals from SDME (complete) ...... 134

Figure 5 - 8 : Hubble Telescope Assembly ...... 135

Figure 5 - 9: Schematic of Main Web-based User Interface for PD-SKMS ...... 136

Figure 5 - 10 : Present Product Data Semantics for Hubble Telescope Assembly-I:

Thumbnail ...... 137

Figure 5 - 11: Present Product Data Semantics for Hubble Telescope Assembly-II: Table

...... 139

Figure 5 - 12 : Design Information in PDB for Base part of Hubble Telescope ...... 139

Figure 5 - 13: Product Data Related to Truss of Hubble Telescope ...... 140

Figure 5- 14: Linking Results from DBpedia and Freebase ...... 141

Figure 6 - 1: Integration Framework of Multiple CAD Applications and PDM System 152

Figure 6 - 2: Extract and Instantiate Product Data Semantics for PDM Ontology ...... 153

Figure 6 - 3: Ontology Mapping and Transfer of Product data semantics ...... 154

Figure 6 - 4: Ontology Mapping and Integration between Multiple Ontologies ...... 155

Figure 7 - 1: Overall framework for on-line community ...... 164

xvi

Dedication

This dissertation is dedicated to my mother and father who provided both emotional and financial support for my education

since I was very young

xvii

Chapter One - Introduction

Along with the greater productivity that CAD automation provides, product development organizations face a whole new set of challenges.

On one hand, the incredible influx on the volume and diversity of product design data that engineers now create through the use of better and more automated design tools needs to be managed, controlled, and shared efficiently for gaining a competitive edge.

However, exchanging and sharing product data between various design tools, e.g.

CAD/CAE/PDM applications, remains a challenging task. This interoperability problem results mainly from heterogeneous data representations used by these different design tools. The heterogeneity leads to the conflicts of semantics due to different ways to describe the same objects and facts or the use of different encodings and conceptualizations for a domain. Some important neutral data formats have been developed, e.g. the standard STEP adopts different application protocols (AP) for each particular industry domain. In order to communicate between different APs, Application

Integrated Constructs (AIC) are defined for common concepts. It is a tedious and complex job to define APs and AICs for numerous domains. The semantic information such as design intent, design history, etc., cannot be represented by STEP. The

PDM/PLM systems today can support information exchange especially in the later phases of the engineering lifecycle. But they lack formal models for product representation which makes possible of the management and reuse of design knowledge.

1

On the other hand, there is an urgent need for creative methods and environments to capture existing design knowledge from engineers, considering a considerable segment of the workforce retiring in the next decade, and to formalize the transfer, storage, and access to that information. This knowledge relied on the personal experience heavily and has to be made explicit to other engineers and across the entire product development processes. However, knowledge capture from human engineer is both haphazard and error prone: different persons may choose diverse annotation terms/ways to capture work processes and decision-making procedures. Consequently, knowledge retrieval is severely limited.

Thus, this dissertation was motivated to investigate to solve the following three questions:

I. How to capture product data semantics from design tools, and thus enable

exchanging product data across the product lifecycle?

II. Is it possible to retrieve product data and derive new product data semantics,

and how to implement it?

III. How to reuse and preserve engineering knowledge for human engineers,

especially in today’s climate of computer-based social networking and

computational literacy?

It is believed that a formal knowledge representation is very promising to solve all these problems. This formal knowledge representation should be: 1) Independent of any one product development process; 2) Open and non-proprietary; 3) Simple and generic;

4) Extensible for broader engineering contexts; 5) Capable of capturing most commonly

2

shared engineering context, etc. Ontology satisfies all these requirements for a formal knowledge representation and the research on ontology has been active in recent years.

Based on the ontology research conducted at VRCIM lab over the past few years, this dissertation utilizes ontology to represent the product data and design knowledge for product engineering domain in a formal way that the computer can understand, interpret and manage product data. Further, based on the ontology models built for engineering domains, this dissertation explores semantic approaches that support exchanging and sharing product data between various design tools on a semantic level and additionally, enable design activities for product data querying and reasoning. Finally an online product design semantic environment built on engineering ontologies for the reuse and preservation of engineering knowledge for engineers on the Web is constructed, by incorporating Semantic Web technologies.

3

Chapter Two - Problem Statement, Proposed Solution, and

Scope of Work

This chapter identifies the higher-level limitations of the current integration frameworks for engineering tools and ontology research in engineering domains. The semantic approaches based on ontology used to address these issues will be introduced briefly. Finally, a description of the scope of work and an organization of the dissertation will be given.

2.1 STATEMENT OF PROBLEM

A product is considered from different viewpoints and perspectives, and different representations and terminologies may be used by each viewpoint. Most ensembles of engineering software tools only understand their own knowledge representations are not adaptable to others; furthermore, there are few general frameworks and approaches for enabling this adaptability. The data formats for these tools vary greatly and, more importantly, the results generated in one system based on its own knowledge representation cannot be understood in another. Product data semantics generated throughout the design process cannot be collected efficiently and are almost always discarded. However, most of present work in this field still stays based within product data itself, STEP, XML or UML models. As an alternative solution, the ontology model seems an evolution. Some research groups have contributed to ontology modeling for

4

different domains in recent years. Ontology modeling has matured gradually and today there are many ontologies existing.

Even some ontologies have been built for engineering domains, most research has still emphasized the enhancement of expressiveness for modeling and simple retrieval of information. However, reasoning abilities in ontologies is one of the motivating factors why the specification needs to be formal in ontology modeling. By ontology querying, facts can be retrieved and by ontology reasoning, facts that are not expressed explicitly can be derived from the ontology. The advantages of reasoning include: more than database style retrieval of facts, extracting implicit information from explicit information provided, etc. Although ontology querying and reasoning are common in fields such as medicine, it is only recently that there is an evolution to this next step in product engineering.

Lastly, knowledge-based systems nowadays are anticipated to support creative design in various ways such as by providing better user interfaces, bigger knowledge bases, better knowledge representations, and a computational model with flexible search mechanism. However, past approaches for knowledge representation and retrieval such as rule-based expert systems and case-based reasoning methods are outdated and ineffective in today’s climate of computer-based social networking and computational literacy. It would be significant to create an on-line community that links engineers in a more professional setting with the ability to share non-proprietary models and information and provide an opportunity to trouble-shoot problems together.

In summary, it is becoming increasingly important for people to share product data semantics and rationale in such a way that there exists a true integration of the

5

product model data and support for diverse compositions with engineering application

ensembles and diverse viewpoints, especially in a more interactive design environment

by utilizing Internet nowadays..

2.2 PROPOSED SOLUTION

The proposed approach is to utilize semantic approaches based on ontology as the

solutions for issues discussed in the previous section. An ontology-driven integration

framework provides an environment for the variety of applications involved in the design

process to describe a design/simulation decision in a formal knowledge representation.

Ontology querying and reasoning mechanisms are applied on engineering ontologies to

retrieve out existing product data and most importantly, infer new product data semantics

for knowledge discovering. Further, an online knowledge-contextual design environment

is designed to reuse and preserve engineering knowledge for engineers on the Web by

adopting Semantic Web technologies.

2.3 SCOPE OF RESEARCH

The research described in this dissertation focuses on realizing the solution

proposed above through design, integration and implementation of the following:

1) Knowledge representation and integration for product data: an ontology- driven integration framework that would allow applications in engineering design/analysis domains to share and exchange design semantic information has been proposed and implemented. More applications of PDM, PLM, ERP, etc. can be integrated

6

into this ontology-driven integration framework which makes it possible to exchange and

share product data across the product lifecycle;

2) Querying and reasoning for product data semantics: approaches to apply ontology reasoning mechanisms on engineering ontologies in local-based or Web-based applications through rule definitions ontology will be investigated. Querying and reasoning allow retrieving existing product data and deriving new product data semantic not explicitly expressed in the knowledge bases. It is believed that the reasoning mechanism exploits and extends the knowledge representation made possible through ontology and holds promise for improved knowledge discovery and understanding;

3) Knowledge Acquisition and Management: based on the research on 1) and

2), an online product semantic design environment will be designed to, specifically for engineers, enable engineers to present queries and requests to a community for an exchange of ideas, knowledge, problems, and solutions for product design. With this approach, knowledge of engineering design, captured in computational models, can be acquired and integrated with engineering tools and workflows, and thus these models and enhanced engineering tools used in conjunction with an on-line community for engineers will allow reuse and preservation of certain kinds of engineering knowledge.

The ultimate objective of this research is to advance the product design process towards automatically and intelligently.

7

2.4 OVERVIEW OF THE DISSERTATION

The dissertation consists of three full size papers that are being submitted to journals for publication. It is organized as follows:

Chapter 3, “Semantic Integration of CAD/CAE Applications Based on Ontology

Modeling: Strategies and Comparisons” describes the integration framework, including a description about the working mechanism of this framework to overcome heterogeneity of product data representations and integrates engineering tools in CAD/CAE/PDM.

Chapter 4, “Semantic Applications Enabling Reasoning in Product Assembly

Ontologies – Moving past Modeling” describes ontology querying and reasoning mechanism applied on engineering ontologies. Multiple and complex queries and inferences are implemented and applied on product data, thus allow reasoning on assembly information in product assembly domain to obtain information not readily available from a CAD system.

Chapter 5, “Online Semantic Knowledge Management for Product Design Based on

Product Engineering Ontologies” takes advantage of research in Chapter 3 and Chapter 4 and constructs an online knowledge-contextual design environment which allows to present, query & author product design knowledge in engineering domains.

Chapter 6 discusses an extension work on ontology-driven approach to PDM system.

Chapter 7 discusses conclusion and future work

Since all the papers are self-constrained and all the research topics are based on or motivated by the ontology project supported by National Science Foundation (NSF), there will be some repetition in introduction, literature reviews, framework descriptions

8

and references. In addition, because these three manuscripts are to be published

/submitted to three different journals where styles vary, these manuscripts, therefore, are written in the style specified by the journal(s).

9

Chapter Three - Semantic Integration of CAD/CAE

Applications Based on Ontology Modeling: Strategies and

Comparisons

ABSTRACT

In this paper we present a detailed exploration of a semantic approach based on ontologies for integrating product data between multiple CAD/CAE applications. To make this demonstration meaningful, the integration process are implemented for two

CAD applications in a single Product Design Domain, and then two applications in different domains, one CAD application in Product Design Domain and the other CAE application in Assembly Simulation Domain. In addition, this ontology-driven approach is compared with data model language UML as well as a traditional file transfer approach. It is concluded that the ontology-driven approach is superior for solving heterogeneous data problems involving multiple applications by managing data at a semantic level.

Keywords: CAD/CAE application, Product data, Engineering ontology modeling,

Semantic integration

1. INTRODUCTION AND MOTIVATION

Great progress has been made in the development of software tools in Computer

Aided Design (CAD) and Computer Aided Engineering (CAE) areas. However, exchanging and sharing product data between various CAD/CAE applications remains a

10

challenging task because of interoperability problems resulting mainly from heterogeneous data representations used by these different tools. Different ways to describe the same objects and facts or the use of different encodings and conceptualizations for a domain lead to conflicts of semantics [1]. For example, a design feature in a 3D feature-based CAD application is not necessarily meaningful to an analysis application which is based on the concept of mesh elements, although both applications are referring to the same product. Even in the same domain, different tools use their own terminology to describe the product data.

Some important neutral data formats, such as STEP-ISO 10303 [2], IGES have been developed for the exchange product data between engineering tools. However, these neutral data formats usually operate on a data level and they are not self-describable. For example, in order to enable communication between engineering tools in different domains, STEP defines application protocols (AP) for each particular industry domain as well as Application Integrated Constructs (AICs), which are defined for common concepts of APs, allowing communications between different APs. It will be tedious and complicated to define APs and AICs for numerous domains. Additionally, in some cases,

APs cannot be fully supported by special applications belonging to the same particular industry domain. Also, important design information including design intent, design history and rationale cannot be represented by STEP currently. Important work in this field, such as creating new application protocols based on shared resources and capturing design intent with EXPRESS language, is ongoing.

In this paper, we seek a different approach to improve the traditional data transfer process by introducing and utilizing a formal knowledge representation. A formal

11

knowledge representation needs to be: 1) Independent of any one product development process; 2) Open and non-proprietary; 3) Simple & generic; 4) Extensible for broader engineering contexts and 5) Capable of capturing most commonly shared engineering contexts [3]. Ontology shows promise in all these, because ontology enables an exact description of things and their relationships by providing a vocabulary for representing knowledge in a domain. Additionally, ontology supports querying and inference functionalities on information represented by ontology models.

This paper expands upon ontology research conducted at Washington State

University over the past few years [4-8] and has a deeper discussion about the ontology modeling for product engineering domain and strategies to integrate product data semantics between CAD/CAE applications based on these ontology models. In addition, we compare ontology-based modeling with a traditional modeling tool UML and ontology-driven integration with a traditional data transfer approach.

The literature review and background section describes present status and development of ontology modeling for engineering domains and introduces conventional data transfer approaches for engineering tools. The following section lays out clearly the objectives of this work which can be partitioned into four areas. The next two sections provide the details on ontology modeling for product assembly domain and strategies for integration of engineering applications on product assembly information based on their ontology models. Finally, the ontology-driven approach is compared with other existing technologies in terms of different aspects and its advantages are highlighted.

12

2. LITERATURE REVIEW AND BACKGROUND

2.1 Product data representation for Integration Framework of Engineering

Applications

In a design/analysis integration framework, different applications working on the same product design need to exchange information based on the product information model. Hence, an integration framework needs to coordinate heterogeneous tools and product models in a unified and streamlined manner and provides an infrastructure for explicitly capturing information flow and engineers’ rationales in the product design and analysis processes. Product data representation has been identified as a key issue for the integration of engineering applications for a long time by research groups [9, 10] and the industry [11].

There have been some frameworks proposed for integration of engineering services and application, focused on solving the problem of interoperability and usually these frameworks are based on standard exchange formats, such as STEP, IGES, etc. For example, the Product Life Cycle Support (PLCS) supported by Organization for the

Advancement of Structured Information Standards (OASIS) based upon STEP

Application Protocol 239 (Product Life Cycle Support), is to establish structured data exchange and sharing to support complex engineered assets throughout their total life cycle [12]. The Long Team Archiving and Retrieval (LOTAR) based on STEP AP203 and AP214, develops global standard based archival and retrieval mechanisms for digital product and technical information and it will achieve this through the ongoing harmonization and standardization efforts of Aerospace and Defense organizational affiliations [13]. The standard exchange formats, such as STEP, are characterized by pre-

13

built concepts and relations which are used to promote interoperability. In this kind of integration framework, all the data exchanged must use the same format.

2.2 Conventional Data Transfer Approaches

The data transfer approaches make product data of one engineering application accessible to other applications and thus help exchange product model information between engineering applications in a design/analysis integration framework. There are some factors to consider when choosing the approaches. The capability of keeping the fidelity of original data without any loss of data is still challenging for conventional product data transfer approaches for engineering domains.

PRO/E and CATIA are commercial CAD software designed for creating feature- based parametric models in professional fields such as engineering and architecture.

Commercial conversion software, such as AccuTrans 3D [14], TransMagic [15] and

Spatial’s 3D InterOp Suite [16], etc., offer translators to exchange 3D CAD models between major CAD/CAM systems, such as PRO/E, CATIA, SolidWorks, etc. Usually, these conventional translators provide accurate translation of feature-based 3D geometry as well as many materials attributes between the file formats adopted by popular CAD software or standard exchange formats, such as STEP, IGES, and STP. However, some

CAD data, such as assembly information, still gets lost through the translation process. In addition, important design information including intent and rationale are also not sent form source to target systems. A typical example is that the design creation behaviors for features such as a cylinder, is difficult to be captured and come through the conventional product data transfer process from one CAD system to another.

14

A virtual assembly simulation environment called Virtual Assembly Design

Environment (VADE) [17-20] was developed by the VRCIM lab at Washington State

University and it gives the user a natural and intuitive interface for performing assembly operations in an immersive, virtual environment. Computational and graphical data of

CAD models, such as parts and assemblies that are to be manipulated, are imported into this virtual environment for a simulation purpose. In details, the data include the graphical representations of the parts/assemblies and the constraints information between them. To enable the data transfer, Pro/VADE [17-18] was developed to extract necessary

CAD model information from PRO/E and write this information in a format which can be accepted by VADE. Although Pro/VADE solves the problem of data transfer between

Pro/E and VADE, it is still rather difficult to understand for engineers who are not unfamiliar with the data format and data transfer process in CAD/CAE domain.

This paper will use these three applications: PRO/E, CATIA and VADE as example engineering applications to testify our novel semantic strategies for product data transfer.

For example, our approach will be discussed to solve the interoperability problem between Pro/E and VADE as Pro/VADE does. Moreover, a comparison between

Pro/VADE and this semantic approach based on ontology will be presented in section 6.

2.3 Overview of Ontology Modeling for Engineering Domains

In theory, an ontology is a "formal, explicit specification of a shared conceptualization"[21]. It provides a shared vocabulary, which can be used to model a domain – that is, the type of objects and/or concepts that exist, and their properties and relations [22]. Ontology modeling, consisting of a set of tasks related to the development of ontologies for a particular domain [23], offers a direction towards solving the

15

interoperability problems brought about by semantic obstacles.

Some research groups have contributed to ontology modeling for different domains

in recent years. CYC[24] is an artificial intelligence project that attempts to assemble a

comprehensive ontology and knowledge base of everyday common sense knowledge.

The objective was to codify millions of pieces of knowledge that comprise human common sense in machine-usable form. Research in Germany [25] yielded a fully- fledged ontology for the product and services domain, reflecting more than 25,000 product types in 75,000 ontology classes. However, this ontology is designed for the business domain, e.g. product price and company data, and not a product design domain.

NIST developed Process Specification Language (PSL) [26] as an interlingua for different manufacturing process applications to enable exchange of information. Because its focus is only on manufacturing process-specific data, product data, such as design rationale, function, behavior, and inter-part relationships, cannot be represented by it.

Recently, ontological models based on Core Product Model (CPM) and Open Assembly

Model (OAM) for product representation have been developed [27-29]. Chang and

Terpenny [30] focus on the development and use of an Activity-Based Cost ontology

(ABC ontology) to guide designers to drill down and access information for product family design. Witherell et al. [31, 32] have created a framework for intelligent distributed ontologies in engineering (FIDOE) that is effective in creating awareness of the implications of design changes during the design process in a distributed environment.

Lee and Suh [33] proposed architecture for ontology-based product knowledge and a

Product Web Ontology Language (POWL) based on OWL. Their architecture consists of three-levels of ontologies: meta, generic and particular product ontology. Djuric et al. [34]

16

define the Ontology Definition Metamodel (ODM) in the context of a Model Driven

Architecture (MDA). They improved ODM by redefining it with a Meta-Object Facility

(MOF), to define an OWL-based UML profile allowing UML notation in ontology engineering. Kim et al. [35] developed a type of formalism, called AsD that represents assembly and joining relations. This formalism generates Assembly Relation Model

(ARM) mapped with a corresponding CAD model and the Ontology-based Assembly

Model (OAM) is developed as an ontological representation of ARM. The new AsD, enhanced by ontology, is able to process queries about assembly information and act as a medium for selective assembly design information sharing. Different from their research scope, the research work in this paper is strongly motivated by the ultimate goal of transferring assembly and constraint information between CAD/CAE applications.

3. RESEARCH OBJECTIVES

The overall objective of this paper is to prove the capability of semantic strategies based on ontology for complex design evaluations involving multiple applications both within and across domains and demonstrate its advantages over traditional methods.

Specifically, the following issues are studied in this paper:

1) Propose an ontology-based strategy for knowledge representation of various applications in multiple product engineering domains. In this paper, two engineering domains are considered: Product Design Domain and Assembly Simulation Domain.

2) Investigate a semantic strategy to transfer product data semantics between engineering applications. In this paper, an approach is provided to integrate two applications in the same domain and then two applications in two different domains as shown in Figure 1.

17

3) Compare ontology modelling with a traditional data modelling approach, UML.

4) Compare semantic strategy approach based on ontology for product data transfer

with a conventional data transfer approach: Pro/VADE. Pro/VADE extracts data from

PRO/E and the data will be transferred to a virtual assembly simulation application.

Figure 3 - 1: Data Integration between Applications within/across Domains

4. ONTOLOGY MODELING FOR KNOWLEDGE REPRESENTATION

Product data semantics is defined as the meaning and the usage of product data. It includes a Knowledge Layer and an Instance Layer. A basic methodology has been adopted to build the Knowledge Layer and the Instance Layer in this paper. The

Knowledge Layer describes basic knowledge within any domain by using concepts, relations between these concepts, and axioms applied on relations. The Instance Layer associates actual product data to the Knowledge Layer by instantiating concepts of the

Knowledge Layer. The process of creating Instance Layer is called product data instantiation. The relationship between these two layers is displayed in Figure 2.

18

Figure 3 - 2: Relationship between Knowledge Layer and Instance Layer of Product

Data Semantics

Reliable sources, including books, documentation and human experts, were

referred to determine the most common and acknowledged generic terminology that

can be defined in Knowledge Layer of engineering ontologies. All the ontologies are

coded with OWL using an editor Protégé-OWL [36] and some of our initial work is

described in our other papers [4-8].

4.1 Fundamental Layered Structure of Engineering Ontology

We use a 3-layered ontology structure (Figure 3) that consists of:

1) General Domain Ontology (GDO)

2) Domain Specific Ontology (DSO)

3) Application Specific Ontology (ASO)

Ontologies at each layer inherit ones at the previous layer and also extend them by incorporating more specific data semantics into the whole structure. These three layers will be discussed in more details in the following sections.

19

Figure 3 - 3: Structure and Deployment of 3-tier Ontologies

4.1.1 Modeling of General Domain Ontology (GDO)

GDO, at the upper level of this structure, describes basic elements representing

commonalities that can be applied to any domain of product design/analysis.

Three concepts are defined in GDO: Component , Geometry and Behavior .

Component describes the very basic elements of product models. The lower-level ontology, such as PRO/E Application Ontology (PRO-AO) in Figure 3, embodies

Component with sub concepts, e.g. Part and Subassembly . Geometry represents knowledge about basic geometry information of product models. Feature Based

Modeling Domain Ontology (FBM-DO) in Figure 3 inherits this concept and develops sub concepts of it, such as Solid , Curve , etc. Behavior is defined to capture the design

intent and design history , e.g. the way a 3D feature is created, imposed actions of

assembly operations, etc. This paper mainly focuses on the definitions of Component and

Geometry . The discussion about Behavior will be conducted in the future work.

20

Properties defined in GDO are: is-a, has_ part_of, has_attribute_of . Is-a and has_ part_of reflect the inheritance and composition relations between concepts, respectively.

And h as_attribute_of defines the relations between a concept and its attributes.

4.1.2 Modeling of Domain Specific Ontology (DSO)

Each DSO reuses the concepts and properties in GDO and defines specific

concepts/properties for a particular domain. In this paper, DSOs are created for the

following domains: feature-based geometric modeling domain (FBM-DO), constraint-

based assembly modeling domain (ASM-DO), product simulation modeling domain

(SIM-DO), etc. Figure 4 depicts concept definitions in FBM-DO (Figure 4.I) and ASM-

DO (Figure 4.II). For example, ASM-DO is used to capture common knowledge for the

assembly design. Although engineering applications adopt different terminology to

represent the assembly constraints, these spatial assembly constraints can be categorized

as LineToLine , LineToSurface , SurfaceToSurface and ToCoordinateSys in ASM-DO

(Figure 4.II).

Figure 3 - 4: Definition of Concepts in FBM-DO and ASM-DO

21

4.1.3 Modeling of Application Specific Ontology (ASO)

ASO is at the lowest-level of the 3-layered ontology structure. Based on GDO and

DSO, it allows introducing more specific concepts/properties for unique applications.

Each ASO is created for one specific engineering application. ASOs are used to transfer

the product data semantics between different engineering applications.

In this paper, ASOs are created for three engineering applications in CAD/CAE

domain:

1) PRO-AO : PRO/E Application Ontology

2) CAT-AO : CATIA Application Ontology

3) VADE-AO : VADE Application Ontology

As depicted in Figure 4, PRO-AO and CAT-AO fall under the same domain of

Product Design Domain (PDD), which includes FBM-DO and ASM-DO. VADE-AO

belongs to Assembly Simulation Domain (ASD) which is composed of ASM-DO and

Simulation Modeling Domain Ontology (SIM-DO). In the following sections, we present

the details on the modeling of PRO-AO in CAD domain and VADE-AO in CAE domain.

a) Modeling the PRO-AO : As a commercial design package, PRO/E covers several engineering domains, including geometric modeling that supports feature-based

parametric design and assembly design using spatial constraints.

Concept Definition : PRO-AO inherits concepts from ontologies at higher levels,

e.g. Component from GDO, Component_Constraint from ASM-DO and

Feature_Element from FBM-DO. It also defines concepts, unique defined in PRO/E. As

shown in Figure 5, in order to define constraint concepts for Pro/E application, PRO-AO

inherits concepts from ASM-DO, such as LineToLine , SurfacetoSurface in ASM-

22

DO:Component_Constrain category, and derives Insert, Mate, Align , etc. based on these inherited concepts. Consequently, these constraint concepts specific for Pro/E application, fall under certain constraint types at domain level, e .g. PRO-AO:Mate is categorized as a sub concept of ASM-DO:SurfaceToSurface . With this approach, although different applications, such as Pro/E and CATIA, use different terminology to represent the assembly constraints, the constraint concepts defined in ASOs, such as

PRO-AO and CAT-AO, always can be classified as the same constraint types at higher level. One significant advantage of this inheritance mechanism is that it helps to calculate mapping concepts between different ASOs, as discussed in one of our papers [36].

Figure 3 - 5: Concept Definition of PRO-AO

Property Definition : The definition of property is similar to the definition of concept in ASO. New properties specific for unique application are defined based on the inherited properties from upper-level ontologies. As illustrated in Figure 6, has_constraint describes the relation between a Component and a Constraint. Because

23

this property can be regarded to represent a composition relationship between concepts, it

is defined as a sub property of has_part_of in GDO.

Figure 3 - 6: Property Definition of PRO-AO

Axiom Definition : In Figure 7, restrictions applied on properties are specified for concept Insert according to the knowledge on constraint of insert in Pro/E. These restrictions can be identified as: 1) Insert is classified as a constraint concept belonging to

ASM-DO: SurfaceToSurface ; 2) the referenced feature elements for Insert must be cylindrical surfaces; 3) the location of two components after inserting is Coaxial . By this way, the semantics of Insert can be represented explicitly. The more restrictions are provided, the more semantics about the meaning and usage of concepts will be captured.

One significance of axiom definitions in ontology is that it enables an automated checking on ontology definition in terms of subsumption, equivalence, consistency and

24

instantiation. However, this topic falls under the ontology reasoning domain and goes beyond the scope of this paper. More details on ontology reasoning have been presented in another paper of ours [37].

Figure 3 - 7: Restriction Definition for Insert

b) Modeling the VADE-AO: VADE allows an engineer to consider assembly issues early in the design cycle and enables the user to be immersed in an assembly simulation environment.

Different from CAD tools, VADE-AO focuses on the assembling motions. VADE-

AO incorporates the basic concepts/properties on assembly design domain and also concepts/properties specific for VADE system (Figure 8). VADE-AO defines three kinds of assembly constraint: Mate , Align and Coordinate_Sys , and concepts such as

Constraint_Sequence , Impose_behavior (Rotate, Translate ), Joint , etc., which describe assembly simulation process in VADE.

25

Figure 3 - 8: Concepts Hierarchy in VADE-AO

4.2 Discussion on Layered Structure of Engineering Ontology

There are two advantages of this layered structure for ontology modeling:

1) Allow the extensibility of framework: Ontologies for new domains or applications

can be easily created and plugged into the existing framework by reusing existing

ontologies and incorporating new concepts for that specific domain or application;

2) Improves the efficiency for mapping: Sharing the same concepts from the upper-

level ontologies makes it easier to discover mapping concepts in the lower-level

ontologies [36].

26

In our engineering ontologies, there are 49 concepts defined in PRO-AO in total, and 15 of them are inherited from upper-level ontologies. The percent of shared versus total terms is 30.6%. In VADE-AO, 13 concepts, inherited from upper-level ontologies, form 39.4% of the total concepts defined in it. The concepts shared in common can help discover mapping concepts between ASOs, e.g. ASM-DO:Componment_Constraint , inherited by PRO-AO, CAT-AO and VADE-AO, is used in an mapping algorithm to calculate mapping assembly constraints defined as sub concepts of it in PRO-AO, CAT-

AO and VADE-AO.

5. ONTOLOGY-DRIVEN STRATEGIES FOR INTEGRATION OF CAD/CAE

APPLICATIONS

Once Knowledge Layer of source ASO is built up, it needs to be instantiated with the actual product data from source application and then product data semantics in source

ASO will be transferred to target ASO.

In summary, this ontology-driven strategy for integration can be divided as three stages:

i. Ontology modeling for engineering tools, which has been discussed in Section 4.

The purpose of this stage is to set up Knowledge Layer of ASO for every unique

engineering tool;

ii. Product data instantiation for source ASO. In this stage, the actual product data

from source application are associated with Knowledge Layer of source ASO and

thus Instance Layer of source ASO is created;

iii. Product data transfer from source application to target application. There are two

steps for this stage:

27

a) Instance transfer from source ASO to target ASO. Firstly, ontology mapping

algorithms find mapping concepts/properties between source ASO and target

ASO. And then, the instances in source ASO are transferred and created as

instances of mapping concepts in target ASO. After this step, the instance lay

of target ASO is created.

b) Retrieve of product data semantics from target ASO to target application. The

instances in target ASO are retrieved to the target application and thus

product data in source application is restored in target application finally.

In the following, Section 5.1 and Section 5.2 will discuss the details about stage II and stage III, respectively.

5.1 Extract Data from Source CAD/CAE Application and Instantiate Knowledge

Layer of Source ASO

Most of the commercial CAD/CAE applications provide open API to access product data generated by the application. In our work, the assembly information, including assembly hierarchy structure, components’ names and quantities, assembly constraints between components and geometrical feature elements referenced by these constraints, is extracted from applications by calling these APIs.

The product data instantiation process creates Instance Layer of product data semantics, which associates the actual product data with predefined concepts and their relations in Knowledge Layer. Thus, instances in ASO are the main elements of product data semantics to be transferred between ASOs.

28

5.1.1 Test Case: Extract Product Data from PRO/E and Instantiate PRO-AO

Figure 9 depicts the procedure of extracting product data from PRO/E application

and instantiating PRO-AO. Firstly, Knowledge Layer of ASO, e.g. PRO-AO, is created

for the unique application, e.g. PRO/E, as described in Section 4. Then, Knowledge

Layer of PRO-AO is instantiated by the actual product data extracted from PRO/E. As a

result, a new ontology, e.g. PRO-AO_InsofHEAD_MIRROR.owl , containing product data semantics with Instance Layer, is created. Several APIs, such as J-Link [38] and Jena

[39], and tools, like Protégé, are used in this development.

Figure 3 - 9: Extract and Instantiate Product Data Semantics for PRO-AO

Several assembly models in PRO/E are used to demonstrate this approach. Figure 10 displays two assembly models: one is an engine model (Figure 10.I) for a racecar and the other is a sub assembly of this engine: Engine-Head (Figure 10.II&III). Considering the engine model, which consists of 746 components, including parts and subassemblies, is much more complicated to illustrate our results. In this paper, we adopted the Engine-

Head assembly model, which is composed of nineteen parts and two subassemblies

(Figure 11.I), as the illustrated model.

29

Figure 3 - 10: Engine Assembly Model in PRO/E

Figure 11.II displays the product data semantics of Engine-Head assembly model after the data instantiation process described in Figure 9. 19 Component instances and 2

SubAssembly instances have been created in PRO-AO. For every component instance, the product data, such as its name, quantity, volume, assembly constraints and transformation matrix, are all captured from Engine-Head assembly model and represented explicitly in

PRO-AO.

Figure 3 - 11: Component Instantiation from Engine-Head Assembly Model

30

An example of assembly constraint instance created in PRO-AO is given in Figure

12. There are three assembly constraints between components TIMING_PULLEY_CAM

and CAM_INTAKE in Engine-Head assembly model. One is Mate and the others are both Insert (Figure 12.I). Accordingly, in Figure 12.II, a constraint instance, named

Insert1 , which is corresponding to one of Insert assembly constraints in Figure 12.I, is created in PRO-AO. It can be easily identified that: 1) Insert1 has assembly reference

CAM_INTAKE and component reference TIMING_PULLEY_CAM ; 2) this constraint happens on

Surface11883 of TIMING_PULLEY_CAM and Surface1665 of CAM_INTAKE ; 3) the offset value is 0.0.

Figure 3 - 12: Constraint Instance Example in PRO-AO

5.2 Transfer Product Data Semantics from Source Application to Target

Applications

Once the product data semantics has been created in source ASO, the source ASO is ready to transfer product data to other ASOs.

Conventionally, it has been typically hard to integrate different CAD/CAE tools because of their heterogeneous data representations. In this context, “integration” means

31

transferring CAD model information from one application to another or sharing CAD model information between these two applications without semantics obstacles and without any loss of the information.

There are two types of product data needed to be transferred for an assembly model: one is about geometrical representations of components in this assembly and the other is about assembly constraints between the components. As introduced in Section 2.2, cu rrently, some commercial 3D objects conversion software is able to transfer feature - based 3D geometry between the file formats adopted by popular CAD systems , however the CAD data, such as assembly information, still gets lost through the transfer process.

Hence, in this paper, our ontology -driven approach is motivated to overcome the semantic conflicts due to the heterogeneity of product data on assembly constraint s and thus help transfer assembly constraint information for assembly models between

CAD/CAE tools. Table1 lists several different definitions for assembly constraint in

PRO/E, CATIA and VADE.

Knowledge Description of Rep. in Rep. in PRO/E Rep. in CATIA Constraint VADE Default, Mate, Coincidence, Contact, Offset, Mate, Align, Constraint Type Align, Insert, etc. Angle, Fix, etc. etc.

Offset(value: 0, Orientation: same) Align or Mate (Plane (offset: 0) Coincidence to Plane) Description: planar surfaces become (Orientation: same) coplanar and face in same direction

Insert Contact(cylindrical surface) (only be used with or Align(Axis to cylindrical Coincidence(with central axis of Axis) surfaces) the cylindrical features) Description: two surfaces of revolution become coaxial

Table 3 - 1: Segment of Comparison on Assembly Constraint Definition

between PRO/E, CATIA and VADE

32

In the following sections, two test cases are demonstrated the integration process for a) two CAD applications in a common domain of Product Design Domain, and b) two applications in different domains, one is a CAD application in Product Design Domain and the other is a CAE application in Assembly Simulation Domain.

5.2.1 Test Case 1: Integrate CAD Applications (PRO/E and CATIA) within One

Domain (Product Design Domain)

This test case demonstrates the integration between two CAD tools: Pro/E and

CATIA.

PRO/E and CATIA are chosen in this test case because they are widely used in CAD domain and they fall under the same domain of Product Design Domain (PDD). To transfer product data semantics from PRO-AO to CAT-AO:

Ontology Mapping: First of all, the corresponding concepts/properties between

Knowledge Layer of PRO-AO and CAT-AO should be calculated by ontology mapping algorithms. Our mapping algorithms are based on a layered and shared ontology structure discussed in Section 4. Key mapping strategies are defined to map concepts and properties between ASOs (Figure 13):

• Equivalency : It checks some pre-defined tags in OWL such as

and determines if two concepts (Properties) are defined as

equivalent.

• Constraint Similarity : It compares constraints of concepts written in DL

(Description Logic) or FOL (First Order Logic) and decides how similar two

given concepts are. Jena Rules and an external reasoner such as Pellet will allow

it to find two concepts having same constraints.

33

• Lexical Matching : It exploits a lexical matching algorithm and checks how similar

the names of two concepts are. This logic only shows the probability where two

concepts are similar. Even though two names look similar, the semantic meaning

might be different.

• Attribute Similarity : The geometric, functional, or behavioral attributes of classes

can tell how similar two classes are.

• Composition & Inheritance Similarity : Two composition paths over part-of

relations and transitivity of composition relations over inheritance relations help

finding similar concepts.

• Property Mapping : Most object and data properties attached to a concept in the

source ontology can be mapped to properties of a matching concept in the target

ontology. If a property does not exist in the target ontology, a new property will

be created.

34

Figure 3 - 13: Overall mapping procedure between ontologies

The detailed procedure to find matching concepts is as follows.

1) Start with creating a composition graph and inheritance hierarchies: Create

composition graph for composition relations and class hierarchies for inheritance

relations.

2) Start a matching process based on definitions: Find explicit equivalences based on

definitions and define them as matching concepts

3) Find Constraint Matching: Check if there are classes whose constraints are matched

to those of other classes with the help of the reasoner.

4) Check Lexical Similarity: Check the similarities based on the naming of classes and

properties.

35

5) Calculate Attribute Similarity: Among two composition graphs from two different

ontologies, for each given source concept, calculate attribute similarity between the

source concept and other concepts in target ontology and find all the nodes that have

similar attribute.

6) Find similar Composition Paths: Since the attribute is transitive over the composition

relation, all the classes that has owner relations over the target concept will have at

least the same attribute similarity.

7) Calculate Composition Similarity: Calculate composition similarity and choose the

one with the highest composition similarity and attribute similarity as matching

concept.

8) Calculate Attribute Similarity and Composition Similarity based on inheritance

relation: When composition similarity and attribute similarity can be transitive over

inheritance relation, all their sub-concepts are set to have the same attribute

similarity and composition similarity.

9) Go to 5) until all the candidate concepts are calculated.

10) Human intervention, in case that user need manual operations of concept or property

mappings.

In addition, a Bridge Ontology is designed to capture mapping results after the mapping calculation between different ASOs. More details are explained in one of our papers [7]. Table 2 gives the mapping results of concepts/properties in terms of assembly constraint between Knowledge Layers of PRO-AO and CAT-AO.

36

PRO-AO CAT-AO

Mate_Offset Offset Align Coincidence has_assemblyreference has_firstcomponent

has_componentreference has_secondcomponent

has_assemblyref_item has_firstcomponent_ele has_componentref_item has_secondcomponent_ele

Table 3 - 2 : Mapping Results of Concept/Property between PRO-AO and CAT-AO

Next, the instances in PRO-AO will be transferred to instantiate the mapping concepts in CAT-AO and thus create Instance Lay of CAT-AO. Table 3 shows that assembly constraint instances between TIMING_PULLEY_CAM and CAM_INTAKE in PRO-AO

are transferred to CAT-AO and they are created as assembly constraint instances in CAT-

AO.

PRO-AO CAT-AO

Componen 01-2_CAM_INTAKE1 01-2_CAM_INTAKE1 t Instance TIMING_PULLEY_CAM3 TIMING_PULLEY_CAM3 Insert1 Contact_1 01-2_CAM_INTAKE1: Surface1665 01-2_CAM_INTAKE1:Cylindrical_surf_CINTAKE_1665 TIMING_PULLEY_CAM3:Surface118 TIMING_PULLEY_CAM3:Cylindrical_surf_TPULLEYCAM 83 _11883 Insert2 Contact_2 Constraint 01-2_CAM_INTAKE1: Surface1668 01-2_CAM_INTAKE1:Cylindrical_surf_CINTAKE_1668 Instance TIMING_PULLEY_CAM3:Surface118 TIMING_PULLEY_CAM3:Cylindrical_surf_TPULLEYCAM 90 _11890 Mate3 Coincidence_3 01-2_CAM_INTAKE1: Surface529 01-2_CAM_INTAKE1: Planar_surf_CINTAKE_1668 TIMING_PULLEY_CAM3:Surface TIMING_PULLEY_CAM3: 11642 Planar_surf_TPULLEYCAM_11642

Table 3 - 3: Instantiation of CAT-AO by Product Data Semantics in PRO-AO

One fact should be explained here is that the surfaces in PRO-AO can be mapped as cylindrical or planar surfaces in CAT_AO due to axiom definitions in ontologies. For example, in Table 3, 01-2_CAM_INTAKE1: Surface529 in PRO-AO is mapped as a planar surface in CAT- AO. Actually, this surface is a referenced feature element for constraint

Mate in PRO-AO and concept Mate in PRO-AO is mapped to concept Coincidence in

37

CAT-AO according to our mapping algorithms. Moreover, a restriction

has_firstcomponent_ele only (Point or Line or Planar_surf) is defined for Coincidence in CAT-

AO. This restriction means that all referenced feature elements for constraint Coincidence

must be Point, Line or Planar_surf. Obviously, Surface529 in PRO-AO will be transferred

as a referenced feature element of Coincidence in CAT-AO, based on the above

restriction of Coincidence , this surface instance must be mapped as an instance of

Planar-surf , instead of Point or Line .

Lastly, the product data semantics in CAT-AO is parsed and retrieved to CATIA

application. Figure 14 illustrates a source code segment for these purposes. There are two

functionalities of this code: 1) Redland [40] parses constraint instance information in

CAT-AO ( CAT-AO_InsofHEAD_MIRROR.owl ), including constraint type, referenced

components, etc.; 2) CATIA API (CAA) [41] retrieves above information and creates an

assembly constraint in CATIA, which is corresponding to the assembly constraint in

Pro/E.

Figure 3- 14: Parse Product Data Semantics from CAT-AO and Retrieve Product Data into

CATIA

38

5.2.2 Test Case 2: Integrate Applications across Two Domains (PRO/E in Product

Design Domain and VADE Assembly Simulation Domain)

This test case will demonstrate the integration between one CAD tool and one CAE tool: Pro/E and VADE.

VADE provides a virtual environment for performing assembly operations. Thus,

PRO-AO and VADE-AO fall under two domains in Figure 4: PRO-AO is in Product

Design Domain while VADE-AO is in Assembly Simulation Domain. The following constraint information should be prepared for VADE:

1) Number of parts/sub-assemblies;

2) Name of parts/sub-assemblies;

3) Constraint relationships between the assembled parts/sub-assemblies including type of

constraint and geometry information for mating or aligning object;

4) Final location and orientations of parts/sub-assemblies;

5) Final location and orientation of referenced feature element by assembly constraint.

Specifically, 4) and 5) is required by VADE system since this information enables the assembly operations in VADE. Given final locations and orientations of one component and referenced feature elements by a constraint, VADE can calculate constrained motions for this component and then perform appropriate assembly operations. For example, after applying a planar constraint, the components will be only allowed to a movement along that plane and a rotation about the normal vector of that plane.

39

All Information has been captured in PRO-AO. In previous sections, product data

semantics for 1), 2), 3) have already been explained with examples. This section will give

more details on product data semantics of 4) and 5).

As shown Figure 11 and Figure 15.I, for every component in an assembly, PRO-AO

captures its transformation matrix as the final location and orientation. A property

has_locationmatrix, which is inherited from ASM-DO: has_location , relates every

component with its transformation matrix.

For every constraint (Figure 15.II), PRO-AO captures the location and orientation

of the referenced feature element ( Axis or Surface ) by this constraint, with property has_geodefination , inherited from ASM-DO: has_constraint_def . Particularly, for an

Axis , the two points in space defining the ends of the graphical lines were stored. For a

Surface , three unit vectors and an origin, which can define the unique plane, are captured.

Figure 3- 15: Product Data Semantics in VADE-AO

All product data semantic can be transferred from PRO-AO to VADE-AO by ontology mapping (Table 4).

40

PRO-AO VADE-AO Mate_Offset Mate Align Align has_assemblyreference has_basepart has_componentreference has_assembliedpart has_locationmatrix has_locationmatrix has_geodefination has_geodefination

Table 3 - 4: Mapping Results of Concept/Property between PRO-AO and

VADE-AO

Considering VADE coded in C, Redland is still used to retrieve the constraint information from VADE-AO. VADE will apply this constraint information to assembly operations in a virtual environment. The details about VADE implementation are beyond the scope of this paper, and they are discussed in [17-20].

5.3 Discussion on Ontology-Driven Strategy for CAD/CAE Integration

This section explains our ontology-driven approach for integrations of CAD/CAE tools. Two test cases are demonstrated the integration process for a) Pro/E and CATIA, which are both in a common domain of Product Design Domain, and b) Pro/E and

VADE, which are in different domains: Pro/E is in Product Design Domain while VADE is in Assembly Simulation Domain.

One advantage of this ontology-driven strategy is that once the product data semantics is captured from a particular engineering tool, there is no need to get into API of this tool again for another integration process. In our test cases in Figure 16, once product data semantics in PRO-AO is created, it is ready to integrate with CAT-AO,

VADE-AO and so on. However, because VADE system falls under a simulation domain, instead of a design domain, the product data semantics involved in the integration

41

between Pro/E and VADE is different from the product data semantics transferred between Pro/E and CATIA. For example, in order to perform assembly operations, the product data semantics about location and orientation of components are required to be transferred to VADO-AO from PRO-AO while this information is not necessary for

CAT-AO. Since all product data has been captured in source ASO, different product data semantics may be transferred from source ASO to different target ASOs, just depending on the domain which the target ASO belongs to. It can be concluded that this approach results in a more adaptive and extensible framework allowing the integration of multiple applications across different domains based on knowledge representations of product data.

Figure 3- 16: Ontology-Driven Strategy for Integration of Engineering Tools in

CAD/CAE Domain

42

6. COMPARISON STUDIES BETWEEN ONTOLOGY AND OTHER

TECHNOLOGIES

This section is motivated to compare the ontology-driven approach with other

existing technologies. Two studies are conducted from different viewpoints on ontology.

In the first one, as a data modeling tool, the ontology is compared with a standard

modeling language, UML. In the second one, as a tool for product data transfer, the

ontology-driven approach is compared with a traditional data transfer approach.

6.1 Comparison between Ontology Knowledge Modeling and UML Modeling

UML [42, 43] has been widely adopted by the software engineering community. As

a data model language, it shares some similarities with ontology.

In UML, there are three types of relationship describing the relationship between

classes: Generalization, Association and Composition. They are consistent with the basic

properties of GDO discussed in section 4.1.1(Table 5).

Ontology UML Description is-a Generalization Inheritance relation between classes relations between an object and its has_attribute_of Association attributes has_part_of Composition Composition relation between classes

Table 3 - 5: Mapping between Ontology Properties and UML Association

Figure 17 gives some examples of OWL and their counterparts in UML. For

example, an owl:ObjectProperty has_constraint which describes the relationship between

GDO:Component and ASM-DO:Component_Constraint can be translated to an association of has_constraint between class GDO: Componen t and ASM-DO:

43

Component_Constraint in UML. A UML object diagram is able to depict objects and the links between these objects. An object diagram, shown in Figure 17, depicts the

composition relationships between an instance of SubAssembly and several instance of

Part .

Figure 3- 17: Segments of UML Modeling for an Assembly Model in Pro/E

Compared with ontology as modeling tool, UML has some advantages, such as: 1)

UML can be used to represent ontologies graphically; 2) As a formal language, the meaning of UML’s notion is defined clearly; 3) As a standard, the diagrams of UML can help ontologies be understood more easily, especially by the people proficient in UML.

However, according to our research, we believe that ontology can be regarded as a more advanced data model than UML because:

1) The purpose of UML is on describing and designing object-oriented software

system, not for knowledge representation. As a result, UML’s class model

represents only schema-based semantics of data (classes, attributes, class

structures, etc.), while the ontology can represent additional semantics (data

value, data units, synonym and disjoints lists). Ontology has the ability to

represent any knowledge in the form of a set of concepts and description about the

44

relationship between them. OWL has some concepts, such as allValuesFrom,

someValuesFrom, SymmetricProperty, TransitiveProperty, which have no

counterparts in UML;

2) UML lacks logical foundation as ontology. OWL is a Description-Logic-based

ontology language and exploits the strengths of Description Logics, including

well defined semantics and practical reasoning techniques [44]. Hence, ontologies

support reasoning algorithms and existing high optimized reasoner

implementations.

Referring to Figure 7, ontology modeling allows restrictions defined for concepts.

Moreover, the ontology reasoning mechanism enables knowledge query and

discovery as discussed in our paper [37]. Although UML defines Object

Constraint Language (OCL) to specify application-specific constraints and queries

on UML models, OCL cannot rival ontology currently.

6.2 Comparison between Ontology-Driven Data Transfer Approach with

Traditional Pro/VADE

Pro/VADE is a user defined module to help extract product data, including geometry and assembly constraint information from Pro/E. The data files generated by Pro/VADE module supply VADE with all the information needed to perform assembly operations.

The geometry information is compiled into *.iv files and assembly information is stored in a *.vade file (Figure 18). VADE will read these files to create geometrical representations of parts/assemblies and then apply the constraint during the assembly simulation in a virtual environment.

45

Figure 3- 18: Segment of *.vade file

As discussed in Section 5.2.2, ontology-driven approach enables transfer product data, such as assembly constraints between Pro/E and VADE just as Pro/VADE does.

However, the ontology approach is distinguished from Pro/VADE in four aspects:

1) Communication: Pro/VADE creates *.vade and ontology use OWL as neutral file

to store constraint information. However, *.vade file is a special format that is

only recognized by VADE while OWL is a standard publish by W3C and widely

used between research groups as communicate language.

2) Scalability and Reusability: Pro/VADE only works between Pro/E and VADE

while the product data semantics captured in ontology are readily transferred

between different applications, e.g. Pro/E, CATIA, VADE and so on, as explained

in Section 4.3. Moreover, ontologies for new particular applications can be easily

46

created and plugged into the existing framework by reuse of existing ontologies.

Pro/VADE doesn’t allow for this.

3) Semantics and Reasoning: The data produced by Pro/VADE follows special

requirements from VADE and naturally has no “meaning” unless explanation is

presented along with the data. For example, to understand the *vade file in Figure

17, the engineer must be informed that three unit vectors ( e1, e2, e3 ) and an origin

(or ) define a plane used in a constraint. In contrast, ontology captures product

data at a semantic level and also provides reasoning and querying functionalities.

The meaning and usage of data will be captures based on domain knowledge.

4) Powerful Support: Pro/VADE is still limited to record hierarchy structure of

large-scale assembly. But ontology can easily derive the composition relationship

among a huge amount of components by inference on the properties describing

composition relationship, e.g. has_part , has_subassemlby .

In summary, as a typical conventional data transfer approach, Pro/VADE is limited in interoperability due to its proprietary data format and restricted functionality. An ontology-driven approach offers a compelling alternative for it.

7. SUMMARY AND FUTURE WORK

This paper presents our research on ontology modeling and an ontology-driven approach for integrations of CAD/CAE applications. With this approach, the product data, including its meaning and usage, can be transferred from one kind of representation to another kind and thus different engineering tools in the integration framework is able to collaborate and communicate at a semantic level. By comparing the ontology-driven approach with UML and Pro/VADE, our research proves this approach provides superior

47

support for the integration of heterogeneous data of multiple applications in engineering domains.

There are still several issues which are worth further investigating:

1) Improvement on Integrations of engineering tools : considering the assembly

constraint information usually gets lost during the conventional data transfer

process, this paper focuses on the transfer of assembly constraints in an assembly

between CAD/CAE applications. In the future, the geometry modeling

information, including design intent and history, and materials information will be

transferred between engineering tools using this ontology-driven approach.

Moreover, we will testify this approach with more complex product models in

engineer tools, especially for the integration between design tools and analysis

tools, which is always a challenging problem in the industry. Some work is still

needed to improve current implementations to be more robust and friendly to use.

2) Mapping : This paper does not discuss ontology mapping algorithms. However,

mapping is a very important integral in our framework. We present the details of

ontology mapping approach in other papers. However, for now, there are still no

perfect mapping strategies to handle the mapping for more complicated ontologies.

In the future, research work will conducted in this field.

3) Design Evaluations : This work needs to be extended to more substantially support

design evaluations.

8. ACKNOWLEDGEMENTS

This work was supported by National Science Foundation (NSF) Grant No. DMI

0523052.

48

GLOSSARY OF TERMS

GDO General Domain Ontology DSO Domain Specific Ontology ASO Application Specific Ontology PDD Product Design Domain ASD Assembly Simulation Domain FBM-DO Feature Based Modeling Domain Ontology ASM-DO Assembly Modeling Domain Ontology SIM-DO Simulation Modeling Domain Ontology PRO-AO PRO/E Application Ontology CAT-AO CATIA Application Ontology VADE-AO VADE Application Ontology

REFERENCE

[1] Wache, H., 2003, “Semantic mediation for heterogeneous information sources”, Phd

thesis, University of Bremen, German.

[2] International Organization for Standardization (ISO), "Industrial Automation

Systems, Standard for the Exchange of Product Model Data (STEP)," Geneva,

Switzerland: ISO 10303, 1994.

[3] H. F. Wang and Y.-L.Z, "CAD/CAM integrated system in collaborative development

environment," Robotics and Computer Integrated Manufacturing, vol. 18, pp. 135-

145, 2002.

[4] Zhan, P., 2007, "An Ontology-Based Approach for Semantic Level Information

Exchange and Integration in Applications for Product Lifecycle Management",

Dissertation, Washington State University, Pullman, Washington.

[5] Zhan, P., Jayaram, U., Jayaram, S., 2008, "A Semantic Approach for CAD/CAE

Integration", Proceedings of 2008 NSF Engineering Research and Innovation

Conference.

49

[6] Zhu, L.J., Jayaram,U., Jayaram, S., and Kim, O., 2009, “Ontology-Driven Integration

of CAD/CAE Applications: Strategies and Comparisons”, 2009 ASME IDETC/CIE

Conference.

[7] Kim, O., Jayaram,U., Jayaram, S., and Zhu, L.J., 2009, “An Ontology Mapping

Application Using A Shared Ontology Approach and A Bridge Ontolgy”, 2009

ASME IDETC/CIE Conference.

[8] Zhan, P., Jayaram, U., Jayaram, S., Kim, O. and Zhu, L.J., 2010, "Knowledge

Representation and Ontology Mapping Methods for Product Data in Engineering

Applications", Journal of Computing and Information Science in Engineering, June

2010, Volume 10, Issue 2, 021004.

[9] J. Shah and P. Wilson, "Analysis of Design Abstraction, Representation, and

Inferencing Requirements for Computer Aided Design", Journal of Design Studies,

vol. 10, no. 3, pp. 169-178, 1989.

[10] W. Regli, X. Hu, M. Atwood, and W. Sun, "A Survey of Design Rationale Systems:

Approaches, Representation, Capture and Retrieval", Engineering With Computers,

vol. 16, pp. 209-235, 2000.

[11] NIST, 1996, “Guidelines for the development and approval of STEP application

protocols”, Available online via < http://www.mel.nist.gov/apde/uofs/apguide.pdf >.

[12] OASIS Product Life Cycle Support (PLCS) TC, 2010, “Product Life Cycle Support

DEXs Version R5”, Available online via

open.org/plcs/dexlib/cs01/oasis_cover.htm>.

[13] LOTAR International, 2010, “Why LOTAR?”, Available online via <

http://www.lotar-international.org/why-lotar/mission-objectives-scope.html>.

50

[14] MicroMouse Productions, AccuTrans 3D, Available online via

[15] TransMagic, Available online via < http://www.transmagic.com/products/features>

[16] Spatial, “Spatial’s 3D InterOp Suite of CAD Translation Components Provide

IronCAD Users 3D Model Accessibility”, Available online via <

http://www.spatial.com/news/3d-interop-suite-cad-translation-components-provide-

ironcad-users-3d-model-accessibility >

[17] Connacher, H.I, 1996, "A Virtual Assembly Design Environment", Thesis,

Washington State University, Pullman, Washington.

[18] Chandrana, H.S, 1997, "Assembly Path Planning Using Virtual Reality

Techniques", Thesis, Washington State University, Pullman, Washington.

[19] Jayaram, S., Wang, Y., Jayaram U., Lyons, K. and Hart, P., 1999, “A Virtual

Assembly Design Environment”, Proceedings of the IEEE Virtual Reality, pp172.

[20] Jayaram, S., Jayaram, U., Kim, Y. J., DeChenne, C., Lyons K. W., Palmer, C. and

Mitsui, T., 2007, “Industry case studies in the use of immersive virtual assembly”,

Virtual Reality, DOI 10.1007/s10055-007-0070-x

[21] Gruber, T. , 1993, "A translation approach to portable ontology specifications",

Knowledge Acquisition, 5, pp. 199-199.

[22] Garshol, L. M., 2004, "Metadata? Thesauri? Taxonomies? Topic Maps! Making

sense of it all", Available online via [accessed October

2008].

51

[23] Pouchard L., Ivezic N. and Schlenoff C., 2000, "Ontology Engineering for

Distributed Collaboration in Manufacturing", Proceedings of the AIS2000

conference.

[24] Lenat, Douglas, 2001, "Hal's Legacy: 2001's Computer as Dream and Reality.

From 2001 to 2001: Common Sense and the Mind of HAL", Cycorp, Inc., Available

online via

[25] Hepp, M., 2006, “Products and Services Ontologies: A Methodology for Deriving

OWL Ontologies from Industrial Categorization Standards”, International Journal on

Semantic Web and Information, 2(1): 72-99 (2006)

[26] NIST, Process Specification language(PSL), Available online via

[27] Fenves, S. J., 2002, “A core Product Model for Representing Design

Information”, NISTIR 6736

[28] Fiorentini, X., Gambino, X., Liang, V., Rachuri, S., Mani, M., Bock, C., 2006,

“An Ontology for Assembly Representation”, NISTIR 7436

[29] Fiorentini, X., Rachuri, S., Mani, M., Fenves, S., Sriram, R., 2008, “Description

Logic for Product Information Models”, Proceeding of 2008 ASME IDETC/CIE

Conference.

[30] Chang, X.M., Terpenny, J., 2008, “A Framework for Ontology-Based

Heterogeneous Data Integration for Cost Management in Product Family Design”,

Proceeding of 2008 ASME IDETC/CIE Conference.

52

[31] Witherell, P., Grosse, I., Krishnamurty, S., and Wildeden, J., 2008, “FIDOE: A

Framework For Intelligent Distributed Ontologies in Engineering”, Proceeding of

2008 ASME IDETC/CIE Conference

[32] Rockwell, J., Witherell, P., Fernandes, R., Grosse, I., Krishnamurty, S., 2008, “A

Web-based Environment for Documentation and Sharing of Engineering Design

Knowledge”, Proceeding of 2008 ASME IDETC/CIE Conference.

[33] Lee, J.H. and Suh, H.W., 2007, “OWL-Based Product Ontology Architecture and

Representation for Sharing Product Knowledge on a Web”, 2007 ASME IDETC/CIE

Conference.

[34] Djuric, D., Gasevic, D. and Devedzic, V., 2005, “Ontology Modeling and MDA”,

Journal of Object Technology, Vol.4, No.1, pp.109-128

[35] Kim K.-Y., Manley D. G., and Yang H., 2006, "Ontology-based assembly design

and information sharing for collaborative product development", CAD Computer

Aided Design, Vol. 38, pp. 1233-1250.

[36] Stanford Center for Biomedical Informatics Research, “What is protege-owl?”,

Available online via http://protege.stanford.edu/overview/protege-owl.html.

[37] Zhu, L.J., Jayaram,U. and Kim, O., 2010, “Enabling Reasoning in Product

Assembly Ontologies - Moving past Modeling ”, Journal of Computing and

Information Science in Engineering ---accepted

[38] Parametric Technology Corporation, 2008, PRO/ENGINEER® Wildfire® 4.0 J-

Link User’s Guide .

[39] Dickinson, I., “Jena Ontology API”, Available online via

53

[40] Beckett, D., Redland RDF Libraries , Available online via

[41] Dassault System, CAA V5 Encyclopedia , Available via

[42] Miles, R., 2006, Learning UML 2.0 , O'Reilly.

[43] Cranefield, S., 2001, “UML and the Semantic Web”, Proceedings of the

International Semantic Web Working Symposium.

[44] Baader,F., Calvanese, D., Mcguinness, D.L., Nardi, D., and Patel-Schneider, P.F.,

2007, The Description Logic Handbook , Cambridge University Press

54

Chapter Four - Semantic Applications Enabling Reasoning in

Product Assembly Ontologies - Moving Past Modeling

ABSTRACT

In this paper the authors postulate an approach to introduce reasoning capabilities into ontologies in the product assembly domain in order to truly exploit these logic-based and formal representations for product data. A model containing semantic applications with multiple reasoning units in Logic Reasoning Layer of a layered semantic application architecture is proposed. Retrieval specifications and inference rules in SWRL/SQWRL are defined in these reasoning units. Besides, local-based user interfaces have been developed to allow product engineers to submit reasoning tasks and view querying retrievals or inference results. The approach and semantic applications are illustrated with two case studies in the product assembly domain. It is demonstrated this approach not only enables existing product data to be queried and retrieved, but also enables new product data, that is not explicitly expressed in the ontology models, to be derived. It is concluded that the reasoning mechanism exploits and extends the semantic representation made possible through the ontology and thus holds promise for improved knowledge discovery and understanding.

1. INTRODUCTION

Much of the existing work related to ontologies in the product assembly domain has focused on the modeling of these ontologies. Ontology modeling is engaged in capturing the shared understanding of a domain of interest and providing a formal and machine

55

manipulated model of that domain [1]. Today there are ontology models built for engineering domains and much work has been done on ontology-driven integration of product data. It is proved that ontology improves the traditional data translation process by introducing knowledge representations. The authors have done considerable work in the modeling of product assembly ontologies, including the formulation of mapping algorithms between these ontologies, and these will be discussed in the literature review and background section.

However, a key characteristic of an ontology model is that it allows reasoning capabilities because of the logic-based and formal specifications inherent in the information model. In order to take advantage of this characteristic, this paper moves past ontology modeling and seeks to develop models for meaningful reasoning mechanisms that are applicable for a product engineering domain. Although these investigations are common in fields such as medicine, it is only recently that there is an evolution to this next step in the product engineering domain.

The research in this paper has been motivated by the lack of sufficient models and approaches in the product assembly domain that are able to go past modeling in order to actually realize querying and advanced inference functionality. Specifically, this research allows reasoning on assembly information in product assembly domain to obtain information not readily available from a CAD system. For example, this paper will contribute to solving typical engineering problems in the assembly design domain, such as identifying a component’s design context, interring assembly sequences, automating assembling process and so on. The benefits this research offers to engineers would be: 1)

Access to explicit and formal knowledge expressed about assemblies and components; 2)

56

A light weight approach to query and reason about this knowledge, without returning to the CAD systems or needing CAD licenses; 3) Inference capabilities that CAD systems cannot support; 4) A mechanism to derive new product data which enriches existing

CAD assembly information.

The literature review and background section describes conventional reasoning mechanisms on product data, provides a brief introduction about ontology reasoning, and then reviews recent work on ontology reasoning mechanisms used for product data. The next section lays out clearly the objectives of this work which can be partitioned into simple querying and advanced inference functionality, and then introduces some enabling mechanisms and facilitators for ontology reasoning. The next two sections provide the design of the underlying model and details of the reasoning units which are the most important building blocks of the model. Finally, these reasoning units are synthesized to demonstrate our approaches with two illustrative examples in the product assembly domain. The significance of the semantic applications in enhancing CAD functionalities is discussed.

2. LITERATURE REVIEW AND BACKGROUND

To present the work in this paper clearly, it is necessary to introduce the conventional reasoning approach in product data, ontology reasoning, and status of ontology reasoning applied to product data and engineering domain.

2.1 Conventional Reasoning on Product Data

Reasoning about product information can satisfy design tasks such as verifying conditions for design completeness, maturity, and product qualification and requirements

57

[2]. It is also expected to enable product requirements, design, analysis and test information to be represented in a common language with logic.

One conventional approach to capturing and storing product data from design tools employs database technologies. Researchers in HP [3] present a CAD data object model and interface which captures and stores information related to CAD data. The captured

CAD data objects are saved in separate relational database files according to type.

Systems permitting database queries over data extracted from a CAD system have been developed [4]. Some challenges exist in this approach, e.g. the query system residing outside CAD systems must be transferred to standardized data exchange formats for interoperability with the CAD systems. Franklin, et al. [5] point out that these traditional database systems are not applicable for data management involving heterogeneous but interrelated data. This is because: firstly, not all the data can be fit conveniently into a very structured format in a relational database management system (DBMS) and secondly, DBMS cannot provide an environment for semi-automatically creating relationships or improving and maintaining existing relationships between entities.

Object-role modeling approaches [6] have been used to support query processing and reasoning suitable for engineering analysis and design tasks. These context modeling approaches, e.g. context modeling language (CML), are rooted in database modeling techniques. However, CML is less expressive than ontology languages, e.g. OWL-DL, and does not provide the support for interoperability since it emphasizes the development of context models for particular applications or application domains. Another approach uses case-based reasoning (CBR) systems [7], in which expertise is embodied in a library of past cases containing descriptions of the problems and solutions of them. A new

58

problem is solved by retrieving similar cases whose solutions can be reused and tested for this new one. Hence, CBR relies heavily on previous cases and requires a large number of high quality cases to be effective. As an improvement, CBR can be combined with rules-based reasoning to achieve higher levels of automation. But currently, most rules- based/expert systems still depend on relational databases, which are used to encapsulate the design rules as well as their complex interdependencies on material, production unit, and manufacturer capabilities [8]. As discussed in the previous paragraph, limitations of the database restrict the capture and process of product data from design tools. Murshed, et al. [9] adopt neutral definitions based on STEP and ISO EXPRESS to help facilitate reasoning on product data. They propose a template to help both define explicitly and recognize automatically assembly features for reverse engineering of legacy parts. Some algorithms, such as ACON and graph matching are also adopted for feature recognition.

However, EXPRESS schema language lacks extensibility. It is hard for humans to read and is also difficult for a computer to interpret. Only a relatively small number of software systems that supports STEP can do the interpretation.

Compared with the approaches discussed above, an ontology-driven approach will overcome their limitations by supporting interoperability, representation of complex relationships of product data, and inference on dependencies among context data with reasoning capability. The concrete engineering problems will be presented in Section 5 and 6 to help explain and demonstrate ontology-driven approach.

2.2 Ontology Reasoning

Ontology reasoning is regarded as a tool and service to help users: i) design and maintain high quality ontologies, e.g.: make the ontology meaningful, correct, minimally

59

redundant and richly axiomatic; ii) answer queries over ontology concepts and instances,

e.g. find more general/specific classes and retrieve individuals/tuples matching a given

query; iii) integrate and align multiple ontologies and iv) infer new information based on

existing knowledge. Mainly, the advantages of ontology reasoning discussed in this paper

include: retrieval of facts in more than database style, extracting implicit information

from explicit information provided, and supplying a formal notion of entailment or

logical consequence [10]. Ontologies are considered one of the foundations of the

Semantic Web [11]. Some Semantic Web online applications, e.g. CHIP [12], a guide to

digital museum collections, and TrialX [13], a consumer-centric tool matching patients to

clinical trials, supply information searching and processing services in a meaningful and

intelligent manner for a vast number of users across the internet.

It is widely acknowledged that ontologies have made a significant contribution to

the design and implementation of information systems in the medical field. Further, using

reasoning mechanisms, ontologies have been used to solve problems in the field of

medical terminology, and to integrate and align heterogeneous knowledge sources, in

particular in the field of clinical guidelines and evidence-based medicine [14].

Researchers in Stanford University have done much valuable work in the use of ontology

reasoning in the medicine domain. Fox example, they use the ontologies to evaluate the

geometric model of the subject and deduce the consequences of penetrating injuries [15].

2.3 Ontology Reasoning Applied in Product Engineering

Several research groups have created well respected ontology models for product engineering domain. Some groups have recently begun to investigate ontology reasoning for engineering problems.

60

Researchers in KAIST [16] have integrated a product information model (PIM) and a product rule model (PRM) based on Description Frame Logic (DFL) to support collaborative product engineering environments. For example, during a machining procedure for a hole, rules are executed to identify the operations in an interactive way.

Crowder et al. [17] simplify a large-scale ontology for the user by presenting a fragment of the entire ontology using an ontology querying approach. Lim et al. [18] propose a framework of faceted information retrieval based on semantically annotated product ontology. Their faceted search and retrieval process is as follows: query processing, concept searching, and retrieval of relevant information. Researchers at Purdue

University [19, 20] achieve effective design information retrievals with an engineering ontology (EO)-based computational framework which constructs a structured and semantics-based representation from unstructured engineering documents. Researchers in

Austria [21] propose an engineering supported environment using Semantic Web technologies. By sharing ontologies between users, their framework is able to decrease complexity of finding and interacting with the right information, construct semantic- based organization and access of information spaces. SWRL rules as well as subsumption relations for classes and properties are defined in a neutral format ontology for feature- based design modeling which enhances collaborations among designers [22].

However, most of the work on ontology reasoning in the product engineering domain has mainly emphasized the enhancement of expressiveness required for modeling and simple retrieval of information for knowledge sharing. Although some papers identify the necessity of ontology reasoning for inference during the product design process, they are still in a theoretical or preliminary stage.

61

The authors have worked for the last several years on ontology-driven approaches

for engineering domain [23-30]. We created layered ontology models for the product

assembly domain and “have made significant improvements to the previously presented

ontologies based on renewed clarity of understanding about the fields” [2], including

some preliminary work on ontology reasoning, e.g. defining restrictions for concepts in

ontologies, which allows performing classification and consistency checks on ontologies.

This paper aims to go significantly beyond the current work on ontology reasoning in the

product assembly domain by applying inference rules on relationships among product

data and thus allowing meaningful and complex reasoning on product assembly

ontologies. There are three significant contributions of this paper that differentiate this

work from that of other research groups. This work will result in the ability to:

 Implement a layered and extensible semantic application architecture utilizing

ontology reasoning mechanism to provide reasoning capabilities on ontologies

 Apply multiple and complex queries and inferences on product data

 Allow reasoning on assembly information in product assembly domain to obtain

information not readily available from a CAD system

3. ONTOLOGY REASONING

3.1 Objective

The fundamental objective of the work in this paper is to propose and utilize a model that enables reasoning on product assembly ontologies. The reasoning functionality can be partitioned as follows:

62

 Objective 1: Enable direct query functionality – allowing a light weighted approach

to retrieve CAD assemblies’ information

Existing product data semantics will be retrieved. For example, find component

and constraint instances in ontologies that match given queries about an assembly.

 Objective 2: Enable advanced inference functionality - enabling inference capabilities

which CAD systems cannot support

New knowledge will be derived through rules extension. For example, extract

implicit product information, e.g. inferring assembly constraint based on component

geometry features.

3.2 Some Ontology Reasoning Mechanisms, Facilitators and How We Use Them

Motivated by above objectives, existing ontologies need to be enhanced to allow

queries and rule definitions related to design knowledge. An ontology reasoning

mechanism provides a means to perform these tasks. Some standard languages and

reason engines have been developed across several domains to support the

implementation of an ontology reasoning mechanism. We will introduce a few of them in

a context of the product assembly domain and describe the way they are used in our

approach.

a) SWRL: Semantics Web Rule Language

OWL based ontologies are suitable for logic-based information modeling. OWL DL,

a sub-set of the OWL ontology language, is conceptually based on Description Logic

(DL). It takes advantage of DL’s well defined semantics, formal properties, known

63

reasoning algorithms, and implemented systems [31]. The engineering ontologies in this

paper are coded in OWL DL.

However, there are some weaknesses in the expression of OWL DL [1]. For

example, considering a CAD ontology with concepts and relationships as shown in

Figure 1, a query such as whether two components, e.g. x and y, assemble together cannot be answered even if they are assembled together in the CAD model and in the existing ontology they are both related (“ is_componentreference ” and “ is_assemblyreference ”) to one constraint explicitly. This is because the assembling relation between these two components is implied by the existing product data semantics. Hence, although it is obvious to a human, the computer needs rules and mechanisms to understand it. The bottom line is that by itself the CAD ontology coded in OWL DL is incapable of expressing this implied assembling relation out and thus cannot answer the above question.

Figure 4 - 1: Relation Definitions of Two Components in A CAD Ontology Coded in

OWL DL

To overcome the expressive limitations of OWL and strengthen the expressive power for it, rule languages have been developed [32]. The Semantics Web Rule

64

Language (SWRL) is proposed by W3C as a rule interchange format. This paper adopts

SWRL, considering its relative maturity. Now a SWRL rule can be used to take the

concepts in the ontology and enable inferring the assembling relation between two

components shown in Figure 1.

SWRL Rule Example SWRL: is_componentreference (?x,?z) ∧∧∧ is_assemblyreference (?y,?z) ∧∧∧ Component (?x) ∧∧∧ Component (?y) ∧∧∧ Constraint (?z) → assembleon (?x,?y)

This rule will be explained in Section 5.1 in detail.

b) SQWRL: Semantic Query-Enhanced Web Rule Language

SWRL is a rule language, but not a query language. To also allow queries, W3C

defines a Simple Protocol and RDF Query Language (SPARQL) [33]. Although

SPARQL can query OWL ontologies, it lacks understanding of OWL’s semantics, so

Semantic Query-Enhanced Web Rule Language (SQWRL) [34, 35], a SWRL-based

query language, is adopted in this paper. As an example, in the following SQWRL

specification, named as SQSP1, all parts are returned ordered by their volumes.

SQWRL Specification Example SQSP1(SQWRL): Part(?p) ∧∧∧ has_volume(?p,?v) ∧∧∧ has_name(?p,?n) → sqwrl:select(?n,?v) ∧∧∧ sqwrl:orderBy(?v) Explanation: Conditions: Part p has volume v and has name n Consequence: Return pairs of name and volume for all instances of Part, ordered by the size of their volumes

Note: The sqwrl prefix is used to identify SQWRL operators.

More rule definitions and retrieval specifications will be given in section 5.

c) Reasoning Engines and Toolkits

65

At a higher level, several existing reasoning engines support the ontology reasoning mechanism. However, some DL reasoners, e.g. Pellet [36], FACT++, and Racer, are not sufficient to understand general OWL DL ontologies [37] currently. Some semantic web packages/frameworks, e.g. Jena [38], have implemented their own support for reasoning.

But the specialized inference engine in Jena is not complete yet.

To implement the full OWL DL reasoning, our strategy combines DL reasoners, e.g.

Pellet with semantic web package/frameworks, e.g. Jena. The Protégé-OWL ontology development toolkit [39] supporting Jess [40], provides good support for

SWRL/SQWRL. Our approach adopts it for rule definition and inference.

4. DESIGNING THE UNDERLYING MODEL

4.1 Overall Semantic Application Architecture

In this paper, the term semantic application denotes a layered and extensible application utilizing ontology reasoning mechanisms and thus providing reasoning capabilities on knowledge bases. This layered semantic application architecture is designed by referencing a typical DL system architecture [1]. Based on this, there are three layers in our architecture: Knowledge Base Layer, Logic Reasoning Layer and

Application Interface Layer (Figure 2).

66

Figure 4 - 2: Semantic Application Architecture

Knowledge Base Layer, which is founded on DL, includes a Terminology Box

(TBox) and an Assertion Box (ABox). The TBox introduces the terminology, i.e. the concepts and relations between concepts in a domain, e.g. Component, Constraint, has_constraint in our ontologies for the product assembly design domain. The ABox contains the instances in terms of concepts, e.g. HUBBLE_MIRROR101_HUBBLE_ASSEMBLY and Insert_MIRROR_BASE , which are corresponding instances of concepts Component and

Constraint in TBox, respectively and they are related by a property has_constraint .

Application Interface Layer provides interfaces for human users, e.g. product engineers, to assign querying or reasoning tasks. Logic Reasoning Layer, supported by

SWRL/SQWRL and DL reasoners, generates specifications applied to the knowledge bases and returns the querying retrievals or inference results back to Application Interface

Layer.

In previous work presented by the authors and discussed in the literature review section, the product data has been extracted from CAD/CAE applications, e.g. PRO/E and CATIA, and then instantiated the knowledge layer of an Application Specific

Ontology (ASO) such as PRO-AO and CAT-AO. Therefore, in this paper we now

67

proceed forward accepting that the product data semantics is successfully captured in

Knowledge Base Layer. Specifically, the reasoning capabilities of Logic Reasoning

Layer are applied on ontologies in the product assembly domain. With this layered

architecture, the human user does not need to understand or learn knowledge bases as

well as the reasoning mechanism applied on the knowledge bases.

The semantic application architecture can be local-based or web-based.

4.2 Reasoning Units in Logic Reasoning Layer

A set of reasoning units enabling ontology reasoning mechanisms is a key piece of

our approach and these have been designed and deployed for Logic Reasoning Layer of

semantic application architecture.

Two groups of reasoning units relevant for the domain of product assembly design

are created.

Reasoning Units for Assembly Level: These reasoning units are applied to the product data semantics of assemblies, which includes information, such as component hierarchy structure, components’ names and number of components per assembly, assembly constraints among these components, feature elements referenced by the constraints, etc. Accordingly, the reasoning units support reasoning capabilities such as:

 Query components of an assembly

 Construct composition tree

 Query constraint information for one component or between two components

 Query and infer geometry attributes of constraint reference

 Infer internal relationships between components

68

 Infer assembly sequence

Reasoning Units for Component Level: These reasoning units are applied to product data semantics for individual components, which include information, such as component’s geometry features and feature items for every feature. The reasoning units support reasoning capabilities such as:

 Query geometry feature information for a single component

 Infer possible constraints between any two components

4.3 User Interface in Application Interface Layer

The application interface layer provides user interfaces for human users, such as product engineers, to assign querying or reasoning tasks. Figure 3.I shows the main user interface for the assembly level reasoning tasks. The user can choose different knowledge bases, which capture product data semantics from different assembly models and different entries for the reasoning tasks, such as displaying assembly component list by categories, displaying composition tree, querying constraint information, inferring assembly sequence and browsing the image library of assembly and so on. After the reasoning tasks are executed by Logic Reasoning Layer, the reasoning results are displayed in Pane 1-5. Figure 3.II shows the main user interface for the component level reasoning tasks. The user can choose entries for querying geometry features of single component or inferring possible constraints between any two components. The querying retrievals and inference results will be displayed in Pane 1 and Pane 2, respectively.

Section 6 will exhibit these user interfaces in details with test cases.

69

Figure 4 - 3: User Interface Designed for Semantic Applications

4.4 Sequence of Reasoning

Synthesizing the descriptions about the basic semantic application architecture and details about the reasoning units, Figure 4 gives a complete sequence of this architecture.

A product developer can assign a query or inference task through the application interface layer. The logic reasoning layer translates this task into a specification applying on the

KBs and returns the results to the application interface layer, in which these results are organized and displayed in multiple views. The KBs capture product data semantics for assemblies and components.

The semantic application in this paper is local-based. The shaded part in Figure 4 reveals that Knowledge Bases Layer and Logic Reasoning Layer are transparent to product developers, who only need to interact with ontology-driven Application Interface

Layer. The yellow frames in the logic reasoning layer denote the reasoning units and the grey frames in the application interface layer represent various views of reasoning results.

70

Figure 4 - 4: Overall Sequence of Reasoning for Assembly and Component Levels

5. DESIGN OF REASONING UNITS IN THE LOGIC REASONING LAYER

Two groups of reasoning units relevant for the domain of product assembly design are created in the logic reasoning layer. This section will explain the details of reasoning units step by step.

5.1 Design of Reasoning Units for Assembly Level

A CAD assembly model is a collection of components, comprised of various levels of individual parts and sub-assembly models. When designing an assembly in a CAD system, part to part assembling relations, such as mating and fit specifications and reference features are defined. However, some information is not explicitly available in

71

CAD systems. An assembly model contains key information such as the composition of

the assembly, the hierarchy structure of the assembly, and the assembly constraints

between the components. If this information is expressed out explicitly and formally, it

can also be possibly utilized to derive new information. This is the reason why ontology-

driven approach is a very exciting way to enhance CAD systems, even though some

information can be available directly from CAD systems.

Four key reasoning units will be explained here:

 Reasoning Unit 1( RU1 ): List Components of an Assembly This reasoning unit is designed to express the composition of an assembly.

Typically, this functionality is readily available in CAD systems but we are describing it

here since this reasoning unit is a basic building block for some of more complex

reasoning units. The snippet below demonstrates the connection of Jena with Pellet,

explained in Section 3.2, to retrieve instances of Part and SubAssembly . Consequently, this reasoning unit is able to display components of an assembly by categories of Part and SubAssembly .

Retrieve Instances of Part and SubAssembly

// Jena connects to Pellet model = ModelFactory.createOntologyModel( PelletReasonerFactory.THE_SPEC ); // Load Knowledge Base: PRO- AO_InsofASSEMBLYDEMO_SWRL.owl model.read(ont); model.prepare(); … // Retrieve TBox in Knowledge Base Part = model.getOntClass(namespace+ "Part"); SubAssembly = model.getOntClass(namespace + "SubAssembly"); … // Retrieve ABox in Knowledge Base Iterator subai = SubAssembly.listInstances(); Individual ind = (Individual) subai.next(); … Iterator pi = Part.listInstances() Individual ind = (Individual) pi.next(); …

72

 Reasoning Unit 2( RU2 ): Retrieve and Display Hierarchy Tree in Multiple Views

CAD systems present the hierarchy structure in their user interfaces. Often, this information is required to be expressed explicitly, output, and used by other engineering tools. For example, in our work in the virtual assembly domain, we have come across industry models where surprisingly it is frequently necessary to output the CAD model’s hierarchy and then use another tool to reorganize existing assemblies, or create new sub- assemblies for assembly planning/manufacturing tools such that the new assembly hierarchy represents the actual sequence in which parts and sub-assemblies are assembled together on the shop floor [41]. Currently, many CAD systems, e.g. PRO/E, provide functionality to output hierarchy, but usually in plain text formation.

However, using ontologies, this key information can be represented explicitly and formally for subsequent analysis and manipulation. As a starting point, this reasoning unit retrieves the hierarchy structure captured in the knowledge base and enables the assembly’s hierarchy structure to be displayed in multiple views (Figure 5) which provide more friendly information for engineers. A more powerful reasoning capability for subsequent analysis and manipulation will be introduced into this reasoning unit later.

Figure 4 - 5: Multiple Views of Component Hierarchy in Semantic Application

73

The output of hierarchy structure includes the composition of an assembly as well as

the composition relationship between components. The listPropertyValues method in the

following snippet is applied to the property has_component and returns the instances of

Component which compose an Assembly/SubAssembly . Thus, the hierarchy is constructed by querying the property has_component for every component of this assembly in iterations.

Retrieve Hierarchy Structure for An Assembly

// Retrieve TBox(Concept & Property) in Knowledge Base Assembly = model.getOntClass(namespace+ "Assembly"); Has_Component = model.getObjectProperty(namespace+ "has_component"); … // Retrieve ABox in Knowledge Base, set up the root for the hierarchy tree Iterator Iterator ai = Assembly.listInstances(true); Individual ind = (Individual) ai.next(); … // Retrieve hierarchy by querying property has_component Iterator ci = ind.listPropertyValues(Has_Component); Individual ind = (Individual) ci.next(); …

 Reasoning Unit 3(RU3): Query Assembly Constraints Information

Constraint information is essential for an assembly. It is not only required by other

engineering tools, e.g. assembly reorganizing and assembly planning tools, but also is

important for design decisions. Design decisions for certain parts of an assembly are

usually based on design parameters of other related parts. For instance, when designing a

panel with holes, the diameter of a hole should be adjusted to diameter of its mating

screw. That means the design of the hole will be set in a context of the design of screw or

vice versa.

Thus, some reasoning mechanisms are necessary to determine a component’s design

context which may not be expressed explicitly in CAD systems. Accordingly, this

reasoning unit is designed to help identify the design contexts of components based on

74

assembly constraint information between components. In the following section, a simple example for identifying unavailable design context in CAD systems, by ontology reasoning units, will be given.

Reasoning capabilities are considered for: constraints of a single component and constraints between two particular components.

RU3A for constraints of single component : This capability allows all constraints on a component to be retrieved by querying the property has_constraint for this component. A

Component has_constraint a Constraint means this Component is the component reference of this C onstraint . In PRO/E application, “component reference” refers to the component going to be constrained with respect to another component, i.e. the base component of a constraint, while “assembly reference” of a Constraint is the base component of this constraint.

The retrievals include the components assembling with this component being queried as well as the details of constraints, such as constraint type, referenced feature and offset value. This capability enables constraint information to be retrieved and thus helps identify the design context for one particular component.

Figure 6 shows an assembly model (Figure 6.I) and the constraint details for

PART_B (Figure 6.II) in PRO/E. This reasoning unit (RU3A) queries the constraint information captured in assembly ontology for PART_B and allows PART_B’S constraints to be displayed in multiple visions, as schematically shown in Figure 7.

Compared to the user interface in the CAD system (Figure 6.II), the visions in Figure 7 are more straightforward and easier to understand by structuring the relationship between

75

components and constraints in a table and a graph and also simplifying their

representations from CAD systems.

Figure 4 - 6: A Simple Assembly Model and Constraint Details in PRO/E

Figure 4 - 7: Multiple Views of Constraint Information in Semantic Application

RU3B for constraints between two components : In assembly design tasks, sometimes it is important to identify the design context for every component. For example, considering the assembly model in Figure 6.I, when PART_A is modified, it is very probable that other components, such as PART_B or PART_C, need to be modified accordingly. Here are example questions that may need to be answered:

i) Whether or not two components are assembled directly?

ii) If they are assembled together, what are the assembly relationships between them?

76

iii) What are the answers for i) and ii), if PART_A is assembled with ten or more

components?

The last question is a significant one and the answer is difficult to find out in CAD systems. Because a large-scale assembly model usually involves complex dependency between many components, it would be difficult, at least not efficient figure out the assembling relationship between a mass of components in CAD systems by reading the interfaces, as shown in Figure 7.II, one after another.

This reasoning unit (RU3B) is motivated to analyze, retrieve and present the constraint information between any two components efficiently by answering the above three questions. Specifically, RU3B will make the inquiry for question iii) more straightforward.

However, as discussed in Section 3.2 a), the OWL-coded ontology cannot answer the implied assembling relationships between components. Hence, a SWRL rule (SR1) is defined to derive this relationship that is not explicitly expressed in the knowledge base:

SWRL Rule for Interring Implied Assembling Relationships between Components

SWRL(SR1): has_assemblyreference(?x,?z) ∧∧∧ has_componentreference(?y,?z) ∧∧∧ Component(?x) ∧∧∧ Component(?y) ∧∧∧ Constraint(?z) → has_reference(?z,?x) ∧∧∧ has_reference(?z,?y) Explanation: Conditions: Constraint z has assembly reference Component x and has component reference Component y Consequence: Constraint z has_reference Component x and Component y, i.e. z has x and y as its constraint references.

Note: The property has_reference is a new property being added, which defines the

reference relation between Constraint and Component .

77

A SQWRL specification ( SQSP2 ) will now query property has_reference to retrieve out inferences made by SR1 , i.e. constraints information between two components.

SQWRL Specification for Retrieving Out Inference by SR1

SQWRL(SQSP2): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2) ∧∧∧ Constraint(?con) ∧∧∧ has_reference(?con,?c1) ∧∧∧ has_reference(?con,?c2) → sqwrl:select(?c1, ?con, ?c2) ∧∧∧ sqwrl:columnNames(\"Component #1\", \"Constraint\", \"Component #2\")

Explanation: c_name1 is Component c1’s name c_name2 is Component c2’s name Conditions: Constraint con has instance c1, named c_name1, and instance c2, named c_name2, as its constraint references Consequence: return c1, con, and c2

Supposing SQSP2 is named ContraintQuery, the following snippet is its implementation by using Protégé-OWL development toolkit:

Implementation of SQSP2 with Protégé-OWL Development Toolkit

// Load Knowledge Base: PRO-AO_InsofASSEMBLYDEMO_SWRL.owl swmodel = ProtegeOWL.createJenaOWLModelFromURI(ont_url); swfactory = new SWRLFactory(swmodel); // Introduce query engine of SQWRL to Knowledge Base swqueryEngine = edu.stanford.smi.protegex.owl.swrl.sqwrl.SQWRLQueryEngineFactory.create(swmodel); // Create SQWRL retrieval specification and execute it swfactory.createImp("ConstraintQuery", "…”); //… means SQSP2 definition queryEngine.runSQWRLQueries(); //Get results and process them SQWRLResult result = queryEngine.getSQWRLResult("ConstraintQuery "); …

This is very powerful because this rule inference mechanism extends the knowledge base and consequently answers the question which originally cannot be answered by direct retrievals from the knowledge base. In the above case, the SWRL rule infers about new property has_reference and then sets up a relation ( has_reference ) between the constraints and corresponding components automatically. In this context, the new relation of has_reference between constraints and corresponding components can be regarded as new product data semantics which is implied in the existing assembly ontology and now

78

is inferred and derived from it. The task of SQWRL is retrieving out the inferences made

by SWRL rules (Figure 8).

Figure 4 - 8: SWRL/SQWRL Rule Infers Relation between Constraints and

Components

It should be noted RU3B only can infer components which are assembled directly.

To strengthen this reasoning capability, another reasoning unit valid for any two

components, which may not be assembled directly, will be discussed in reasoning unit 4

after more inference rules are defined

RU3C for geometry attributes of constraint reference: Due to the limited support from

CAD/CAE APIs, the constraint information captured into knowledge base is usually

incomplete. Hence, in our assembly ontology, the exact type of model item referenced by

the constraints cannot be captured from PRO/E application with API directly. For

example, for a PRO/E assembly model, the model items referenced by Mate and Insert

are captured as instances of Surface , but the fact that these surfaces are planar or cylindrical is unknown. The following SWRL rules ( SRGoup1 ) can help infer the exact type of these surfaces:

79

SWRL Rules for Inferring Geometry Attributes of Constraint Reference SWRL(SRGoup1): Mate(?x) ∧∧∧ Surface(?y) ∧∧∧ has_componentref_item(?x,?y) → Plane(?y) (1) Mate(?x) ∧∧∧ Surface(?y) ∧∧∧ has_assemblyref_item(?x,?y) → Plane(?y) (2) Insert(?x) ∧∧∧ Surface(?y) ∧∧∧ has_assemblyref_item(?x,?y) → Cylindrical_surface(?y) (3) Insert(?x) ∧∧∧ Surface(?y) ∧∧∧ has_componentref_item(?x,?y) → Cylindrical_surface(?y) (4) …

Explanation: Conditions: Mate x has assembly/component referenced model item y and y is an instance of Surface Consequence: y is an instance of Plane , i.e. planar surface. Note: rule (1) and (2) are defined for Mate (the similar explanation can be applied to rule (3) and (4) defined for Insert )

Note: Due to limited space, more rules applied to other constraints aren’t enumerated here but they have been implemented in our semantic application.

 Reasoning Unit 4(RU4): Infer Assembly Sequence

This reasoning unit consists of two sub reasoning units.

RU4A for assembly sequence : Assembly sequence is a common but complicated task in the assembly design domain. This paper does not intend to explore an algorithm for it or discuss it in depth. Instead, considering the inference capability of ontology reasoning, this reasoning unit explores the possibility of inferring assembly sequence based on assembly ontologies. In this scenario, a component is picked up randomly as a start, and the reasoning capability is able to tell which components are assembled with this component one by one based on the assembling relationship between them. Figure 9 gives an example assembly sequence for the simple assembly model in Figure 6.I, starting from PART_C. PART_A is marked in red which means it is the base part of this assembly.

80

Figure 4 - 9: A Simple Assembly Sequence Starting from PART_C

A property assembleon and a SWRL rule ( SR2 ) are defined to enable this reasoning unit:

SWRL Rule for Inferring assembleon Relation between Components

SWRL(SR2): is_componentreference (?x,?z) ∧∧∧ is_assemblyreference(?y,?z) ∧∧∧ Component(?x) ∧∧∧ Component(?y) ∧∧∧ Constraint(?z) → assembleon(?x,?y) Explanation: Conditions: Component x is component reference of Constraint z, and Component y is assembly reference of Constraint z Consequence: Component x assembles on Component y

Note: The difference between SR1 (for property has_reference ) and SR2 lies in their

asserted consequences. As explained in the previous section, SR1 relates a constraint to

components and hence can retrieve relevant components as well as the constraint

information between them while SR2 only cares about the components’ relationship

(assembleon ) instead of how they are assembled with constraints.

As shown in Figure 10, the assembly sequences are constructed by relating relevant components one after another along the directionality of “ assembleon ”. Figure 11

illustrates the iteration process for the implementation: start with one component x, the

inference returns a list of components which x is assembled on, and then the iteration is

entered to query property assembleon for every component in the current list.

81

Figure 4 - 10: Construction of Assembly Sequence by Inferences of SWRL Rule

Figure 4 - 11: Iteration Process for Inferring Assembly Sequence

We have to declare that the assembly sequences, inferred by constraints information

between components, are just possible options. For a more accurate solution, some

algorithms, e.g. AND/OR graphs and heuristic search methods in AI, may need to be

integrated to refine a optimized and rational assembly sequence.

RU4B for internal assembling relationship of any two components : compared to

RU3B , this reasoning unit extends reasoning capability to any two components, which

may not be assembled directly, based on the inferences by SR2 (for property

assembleon ).

82

Again considering the simple assembly model in Figure 6.I, let PART_A be the base

part of this assembly; PART_B is fully constrained to PART_A and PART_C is

assembled to this assembly by referencing PART_B. Therefore, RU3B will identify that

design parameters of PART_A very probably affect design parameters of PART_B

because they are assembled together. But no relationship can be inferred between

PART_A and PART_C. However, it is obvious that if the diameter of hole feature in

PART_A is changed, the diameter of hole feature in PART_C needs to be changed

accordingly. The fact is design parameters of PART_A, PART_B and PART_C are

interrelated indeed. For a large-scale assembly, however it would be more difficult to

figure out the internal relationships between components which may not be assembled

directly.

It can be proved that the more closely two components are related, the more probable that their design parameters are interrelated. Two components are closely related if they are assembled directly with some constraints. For two components connected by another component, we also assume they are closely related enough to affect design parameters for each other.

A symmetric property assembledwith (SR3 ) is defined according to assembleon

(SR2 ).

SWRL (SR3): assembleon(?x, ?y) → assembledwith(?x, ?y)

Note: “symmetric” implies if assembledwith(?x, ?y) is true, then assembledwith(?y, ?x)

is also true. The property assembledwith differs from assembleon since it describes the

bidirectional assembling relation between two components without taking into account

83

which component is the component reference and which component is the assembly

reference.

A SQWRL specification ( SQSP3 ) based on property assembledwith is defined to retrieve the connected components as well as the intermediate component between them.

SQWRL Specification for Retrieving Out Inference by SR3 SQWRL(SQSP3): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2) ∧∧∧ Component(?c3) ∧∧∧assembledwith(?c1,?c3) ∧∧∧ assembledwith(?c3,?c2) → sqwrl:select(?c1, ?c3, ?c2) ∧∧∧ sqwrl:columnNames(\"Component #1\", \" Component(in-between)\", \"Component #2\")

In summary, RU3B and RU4B are motivated to help identify a component’s design context by inferring the internal assembling relationship between any components based on their constraint information (Figure 12).

Figure 4 - 12: Internal Relationships among PART_A, PART_B and PART_C

However, there are still some limitations. For example, even if two components are inferred to be interrelated by RU3B and RU4B, it is not necessarily true that one component’s design parameters will be changed with the design parameter of the other in a CAD model. This is because the design context also depends on the geometry features referenced by the constraints between components. For example, if the thickness of

PART_A along the axis’s direction of cylinder feature in PART_B is changed, the

84

parameters of PART_B and PART_C might not be affected. The future work of this

paper will continue research on improving RU3B and RU4B.

Besides these reasoning units, the semantics application for assembly level also

provides other reasoning capabilities, such as RU5: sort components by their volumes by

SQSP1 as shown in Section 3.2 b) and RU6 : retrieve transformation matrix components and several others.

5.2 Design of Reasoning Units for Component Level

Part geometries are created using solid modeling. The reasoning units for component level have been developed to explore the geometry information of a component for assembly design. Considering that detailed descriptions have been provided for reasoning units of assembly level in 5.1, this section is in less detail. The following reasoning units have been designed:

 Reasoning Unit(RU7): Query Geometry Features Information for Single Component

The features, such as Curve, Cut, Hole, Protrusion and model items for every

feature, such as Edge, Plane, Axis, and Cylindrical surface are retrieved for every component in the knowledge base.

 Reasoning Unit(RU8): Infer Possible Constraints between Any Two Particular Components

When assembling components together, they must be positioned and oriented with

respect to each other. In CAD systems, e.g. PRO/E, a pair of mating features for two

components has to be chosen manually to help determine the constraints between these

two components. For example, without Surf0_PART_C and Surf0_PART_B selected

manually by a human developer, PRO/E cannot determine how to assemble PART_C to

85

PART_B (Figure 13.II). Hence, this reasoning unit is motivated to infer the possible

constraints between components without the involvement of mating features’ selection by

human developers and thus help automate the assembling process. For now, three kinds

of constraints: Insert, Mate, and Align are considered for reasoning purpose. Based on the knowledge of constraint definitions in PRO/E, SWRL/SQWRL rules are defined to infer possible constraints between any two components according to their geometry features.

Figure 4 - 13: Two Components (PART_B and PART_C) in PRO/E

RU8A for Insert : there are two possibilities for the occurrence of constraint Insert, which are formulated as rules SQSP4 and SQSP5 .

SQWRL Specification for Inferring and Retrieving Out Constraint Insert (I)

SQWRL(SQSP4): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2 ∧∧∧ has_feature(?c1,?fea1) ∧∧∧ Protrusion(?fea1) ∧∧∧ has_modelitem(?fea1,?item1) ∧∧∧ Cylindrical_surface(?item1) ∧∧∧ has_feature(?c2,?fea2) ∧∧∧ Cut(?fea2) ∧∧∧ has_modelitem(?fea2,?item2) ∧∧∧ Cylindrical_surface(?item2) → sqwrl:select(?c1,?fea1,?item1,?c2,?fea2,?item2) ∧∧∧ sqwrl:orderBy(?fea1)

Explanation: c_name1 is Component c1’s name c_name2 is Component c2’s name Conditions: Component c1 has a Protrusion feature fea1 which contains a cylindrical surface item1 and Component c2 has a Cut feature fea2 which also contains a cylindrical surface item2 Consequence: c1 and c2 can be mated, return c1, fea1, item1, c2, fea2, item2, ordered by fea1

86

SQWRL Specification for Inferring and Retrieving Out Constraint Insert (II)

SQWRL(SQSP5): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2 ) ∧∧∧ has_feature(?c1,?fea1) ∧∧∧ Protrusion(?fea1) ∧∧∧ has_modelitem(?fea1,?item1) ∧∧∧ Cylindrical_surface(?item1) ∧∧∧ has_feature(?c2,?fea2) ∧∧∧ Hole(?fea2) ∧∧∧ has_modelitem(?fea2,?item2) ∧∧∧ Cylindrical_surface(?item2) → sqwrl:select(?c1,?fea1,?item1,?c2,?fea2,?item2) ∧∧∧sqwrl:orderBy(?fea1)

Explanation: c_name1 is Component c1’s name c_name2 is Component c2’s name Conditions: Component c1 has a Protrusion feature fea1 which contains a cylindrical surface item1 and Component c2 has a Hole feature fea2 which also contains a cylindrical surface item2 Consequence: c1 and c2 can be mated, return c1, fea1, item1, c2, fea2, item2, ordered by fea1

For example, PART_B and PART_C (Figure 13) can be constrained by Insert with

Surf0_PART_B and Surf0_PART_C considering Surf0_PART_B is a cylindrical surface of a Protrusion feature and Surf0_PART_C is a cylindrical surface of a Cut or Hole feature.

RU8B for Mate/Align: There is one possibility for the occurrence of constraint

Mate/Align with surface when both the components contain planar surfaces ( SQSP6 ):

SQWRL Specification for Inferring and Retrieving Out Constraint Mate/Align for Surface

SQWRL (SQSP6): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2) ∧∧∧ has_feature(?c1,?fea1) ∧∧∧ has_modelitem(?fea1,?item1) ∧∧∧ Plane(?item1) ∧∧∧ has_feature(?c2,?fea2) ∧∧∧ has_modelitem(?fea2,?item2) ∧∧∧ Plane(?item2) → sqwrl:select(?c1,?fea1,?item1,?c2,?fea2,?item2) ∧∧∧ sqwrl:orderBy(?fea1)

For example, PART_B and PART_C (Figure 13) can be constrained by Mate or Align with planar surfaces: Surf1_PART_B and Surf1_PART_C.

RU8C for Align: there is one possibility for the occurrence of constraint Align with axis when both the components contain axis ( SQSP7 ):

87

SQWRL Specification for Inferring and Retrieving Out Constraint Align for Axis

SQWRL (SQSP7): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2 ) ∧∧∧ has_feature(?c1,?fea1) ∧∧∧ has_modelitem(?fea1,?item1) ∧∧∧ Axis(?item1) ∧∧∧ has_feature(?c2,?fea2) ∧∧∧ has_modelitem(?fea2,?item2) ∧∧∧ Axis(?item2) → sqwrl:select(?c1,?fea1,?item1,?c2,?fea2,?item2) ∧∧∧ sqwrl:orderBy(?fea1)

For example, PART_B and PART_C (Figure 13) can be constrained by Align with axes:

A1_PART_B and A1_PART_C.

For now, these inferences can find all pairs of mating features/ feature items for every kind of constraint that might occur between two components. More rules are being considered to filter out reasonable results.

5.3 Tabulation of Reasoning Units

In summary, eight reasoning units including their sub units are designed and deployed in the logic reasoning layer of semantic applications for product assembly domain, as listed in Table1. Some reasoning units enable direct query functionality on knowledge bases using Jena and Pellet, e.g. RU1, RU2 and RU7 while others enable advanced inference functionality to derive new product data semantics through rules extension(SWRL+SQWRL), e.g. RU3B, RU3C, RU4A, RU4B, etc.

88

Reasoning Capability Approach & Rules Unit(RU) RU1 List assembly component Query (Jena + Pellet) RU2 Construct composition hierarchy Query (Jena + Pellet)

RU3A Retrieve Single component Query (Jena + Pellet) assembly Inference(SWRL+SQWRL): RU3B Two components RU3 constraint for SR1 , SQSP2 Infer geometry attribute of constraint Inference(SWRL+SQWRL): Assembly RU3C Level reference SRGoup1 RU4A Infer Assembly Sequence Inference(SWRL+SQWRL): RU4 Infer internal relationship of two RU4B SR2 ,SR3 , SQSP3 components RU5 Sort components’ volume Inference (SQWRL): SQSP1 Retrieve component’s transformation RU6 Inference (SQWRL) matrix RU7 Retrieve component’s geometry features Query(Jena + Pellet) RU8A Infer Insert Component Inference(SQWRL): Level constraints RU8 RU8B Mate/Align (surface) SQSP4 ,SQSP5 , between SQSP6 ,SQSP7 RU8C components: Align( axis)

Table 4 - 1: Summary of Reasoning Units

6. SYNTHESIS OF REASONING UNITS IN ILLUSTRATIVE EXAMPLES

We will illustrate the reasoning process with an example of a Hubble telescope

model. The model was created as part of a project to extract assembly information and

adapt it for use in a virtual assembly environment simulation.

In the test case presented here, it is assumed that the product data information has

been previously extracted from PRO/E models with J-Link API [42], and used to

instantiate an application specific ontology called PRO-AO with Jena API [25]. The

ontology reasoning tasks in this paper all apply to knowledge bases of PRO-AO. We

begin by observing that the CAD system is incapable of the certain functionalities related

to representation of some product data explicitly and ability to make query and inference

89

on product data. A successful reasoning outcome from ontology enhanced by the reasoning units would be determined by the ability to answer questions such as the following:

1. What are the assembling relationships between two selected components in the

Hubble telescope assembly?

2. Is it possible to infer an assembly sequence for the Hubble telescope components?

3. Is it possible to infer the design context for a component?

4. Is it possible to infer constraints between any two components given their geometry features?

Several APIs and software such as Jena, Pellet, Protégé-OWL 3.4 and Protégé-

OWL ontology development toolkit, are adopted in the development of semantic applications.

6.1 Test Case for Assembly Level

The Hubble Telescope (Figure 14.I) is the first space-based telescope in the world which collects various images from space. Since the telescope has been used since 1990, some components needed to be repaired or redesigned subsequently in order to improve the quality of images sent back to Earth. The simplified assembly model in PRO/E

(Figure 14.II) includes 46 parts and 4 sub-assemblies. Specifically, Figure 14.III shows the optical system of Hubble Telescope, which consists of two mirrors, support trusses, and the apertures (openings) of the instruments.

90

Figure 4 - 14: Example Assembly: Hubble Telescope

Figure 15 is the main user interface of the semantic application for assembly level.

Highlights of using RU1, RU3A and RU3C for querying component and constraint information:

 Pane 1: Component List – What are the parts in this Hubble Telescope assembly?

All instances of Part, not SubAssembly , in the Hubble Telescope assembly

are selected to be displayed ( RU1 ).

 Pane 2: Component Info - What are the details about Part HUBBLE_TOPMIRROR ?

After selecting this component from Pane1 ,

HUBBLE_TOPMIRROR30_HUBBLE_TRUSS_ASM214_HUBBLE_ASSEMBLY , its

information, such as the name: HUBBLE_TOPMIRROR , the type: Part and the

constraints information: Insert41 and Align5 are retrieved and displayed in Pane

2(RU3A ).

 Pane 3: Constraint Info and Pane 5: Constraints Graph – What are the details

about constraints on Part HUBBLE_TOPMIRROR?

91

Insert41 and Aligh5 are displayed in two forms: a table in Pane 3 and a graph

in Pane 5 (RU3A ). Checking Pane 3 further, Surface66 (item in blue shadow),

referenced by Insert41 , is inferred as a cylindrical surface by RU3C .

Figure 4 - 15: Main User Interface of Semantic Application for Assembly Level

Highlight of using RU2 for constructing composition hierarchy: What is the composition hierarchy of Hubble Telescope assembly?

Based on the assembly hierarchy information retrieved from assembly ontology, a composition tree is constructed and presented in multiple views (Figure 16). Moreover, a function enabling the modification of hierarchy tree is designed. In future work, the modified hierarchy will be rewritten to PRO-AO, and then accordingly update the assembly model in PRO/E.

92

Figure 4 - 16: Composition Tree Constructed for Hubble Telescope Assembly

Highlight of using RU3B and RU4B for inferring internal assembling relationship

between two components: What is the design context for any component, e.g. Lens

Truss , in the optical system of Hubble Telescope or which components will very

probably be modified if one component, e.g. Lens Truss is going to be redesigned?

In Figure 17, RU3B and RU4B help find out the design context for one component,

e.g. Lens Truss . Table 2 summarizes the inference results of these two RUs and specifies how Lens Truss, Second Mirror, Mirror Truss , Primary Mirror and Telescope Base in the optical system of Hubble Telescope (Figure 14.III) are interrelated to each other.

For example, Lens Truss is constrained to Primary Mirror by Mate18, which is marked in red in Table 2. This means if some design parameter of mating surface of Lens Truss, e.g. position or orientation, is changed, the product designer should consider redesigning

the mating surface of Primary Mirror . Also, if the product designer considers

redesigning Second Mirror, e.g. its radius, he/she cannot ignore the influence on radius

93

of Mirror Truss as well as Lens Truss , even if Len Truss and Second Mirror aren’t

assembled directly.

Figure 4 - 17: Query and Inference Results about Design Context of Lens Truss

Mirror Truss Second Mirror Primary Mirror Telescope Base (HUBBLE_TOPMIRRI (HUBBLE_TOPMIRROR30 (HUBBLE_MIRROR10 (HUBBLE_BASE18 ROR_TRUSS25_HUBB _HUBBLE_TRUSS_ASM21 1_HUBBLE_ASSEMBL _HUBBLE_ASSEM LE_TRUSS_ASM214_ 4_HUBBLE_ASSEMBLY ) Y) BLY ) HUBBLE_ASSEMBLY ) Lens Truss assembles directly: assembles (HUBBLE_LENS_TRUSS connects by Mirror assembles directly: 18_HUBBLE_TRUSS_AS Align3,Align4, directly: Truss Mate18 M214_HUBBLE_ASSEMB Align Offset19 Align6, Align7 LY ) Table 4 - 2: Summary of Query and Inference Results for Lens Truss

Highlight of using RU4A for inferring assembly sequence: What is the possible

assembly sequence for optical system of Hubble Telescope starting from component

Second Mirror ?

Figure 18 gives an example of assembly sequence starting with Second Mirror ,

HUBBLE_TOPMIRROR30_HUBBLE_TRUSS_ASM214_HUBBLE_ASSEMBLY (yellow item in Figure 18.I), which is labeled as A. In the optical system of Hubble Telescope

94

(Figure 14.III), A is constrained directly to Mirror Truss , labeled as B. Further, B is

queried and can be found being constrained directly to Lens Truss , labeled as C. Hence

C will be put into the assembly sequence after B. That means A assembles to B first, and

then they together assemble to C, and so forth. The sequence finally ends with a base

component of the assembly, E, Telescope Base in this scenario, i.e. the red block in

Figure 18.I. Figure 18.II provides a way to visualize the components in this inferred

sequence in an easy graphical manner. There are limitations as described in the

explanation section of this reasoning unit, but it provides a good candidate starting point

to consider a viable assembly sequence.

Figure 4 - 18: Example of an Assembly Sequence for Optical System of Hubble Telescope

6.2 Test Case for Component Level

Figure 19.III displays the components used in the test case for component level

reasoning tasks. Figure 19.I shows the retrievals of geometry feature information for Part

PULLEY using RU7 . As an illustration, RU8 infers the possible constraints between two

components, PULLEY and AXLE (in Figure 19.II). The inferences include four possible

95

pairs of mating features/feature items for Insert , and quite a few possible pairs of mating features/feature items for Mate and Align , which cannot be displayed entirely in this figure. Although these inferences do not return the expected results exactly, they set the stage for the future work, in which the unreasonable results will be eliminated by introducing new rules and other algorithms.

It should be noted that the ontologies will be checked and verified by the basic inferences, such as checking subsumption, equivalence, consistency and instantiation before applying reasoning tasks. These inferences are done automatically once the ontology is loaded into the model extended with DL reasoning in our implementations.

Other research groups have done considerable work on basic inferences mechanism. This paper does not discuss it since it does not fall under the scope of this paper.

Figure 4 - 19: Ontology-Driven User Interface of Semantic Application for Component

Level

96

7. SIGNIFICANCE OF SEMANTIC APPLICATIONS IN ENHANCING CAD

FUNCTIONALITIES

In this section, the value and benefits that semantic applications offer engineering domain will be addressed specially by discussing how they enhance existing CAD systems.

Firstly, the semantic application captures information from CAD systems through knowledge representations for product data. Although CAD systems, e.g. PRO/E, do supply functionalities to browse assembly hierarchy, component information, and design information, etc., the semantic application in this paper shows that once the product data is captured into knowledge base from a CAD system, it is expressed in a formal and explicit representation which is independent of any particular CAD system. Thus, without further visiting the CAD system or needing the CAD license, the engineers can use this light-weight semantic application to retrieve CAD model information in multiple views which are more straightforward and friendly for human engineers to understand.

Secondly, although the individual CAD API is needed to populate the concepts and properties of the ontology to begin with, going forward, there is no need to get into the

APIs of each individual CAD system to do the retrievals and reasoning. Due to the layered semantic application architecture, the engineers do not have to understand the individual knowledge bases built by knowledge experts for CAD systems, either. In addition, by plugging in more reasoning units in this layered architecture, the semantic application can be extended easily in reasoning capabilities in the future, e.g. accessing more component information such as material, dynamic properties, as well as constraints and geometry features.

97

Thirdly, and most importantly, the advanced inference makes the semantic application provides some inference capabilities that CAD systems cannot support.

Ontology is different from database, programming languages or other modeling tools because it is built on a logic base, which enables an explicit, formal declaration of information model and hence supports inferences by logical rules. In the test cases,

SWRL/SQWRL rules help to infer the design contexts of components, assembly sequence for assembly level and infer constraints between components for component level. For comparison, CAD systems do not provide these inference capabilities currently as semantic applications do.

Lastly but not least, the layered semantic application architecture can be web-based, as discussed in Section 4.1, by implementing the querying/reasoning capabilities of semantic applications on the Web. As a result, the product data semantics is allowed to be shared on Internet. Another paper of ours [43] has proved this approach. In that paper, an online product design environment has been constructed to improve traditional behaviors for design knowledge sharing and exchanging. However, CAD systems are typically local-based and usually they do not support functionalities which enable the sharing of model information on the Web.

The intent of semantic application in this paper is not to replace what is in the CAD system but to provide alternatives to accessing CAD data in explicit and formal representations and inferring new product data semantics implicit but not readily available in CAD systems. Table 3 summarizes advantages of semantic application which are very promising to benefit and enhance CAD systems.

98

Semantic Application for Basic CAD System Enhancing CAD Systems Represent product data in Motivation of Application Design and create model of product knowledge and apply reasoning Development on it Formal and Logic-Based No Yes, represented in ontology Knowledge Representation Inference on Product Data No Yes, through logical rules Multiple Views of Product Yes, data can be organized and Usually no; limited by CAD system Data displayed in any view Powerful in visualization of models; Poor in representing data explicitly; Easy to access and light weight Access of Product Data Need substantial computer resources application and CAD license to run Not complete, focus on Completeness of Product Contains all modeling information particular domain, but open to Data extension User Interface Friendly after a learning curve Friendly to use without training Shared on Internet Usually local-based Yes, can be web-based

Table 4 - 3: CAD System VS. Semantic Application

8. SUMMARY

This paper seeks to create semantic applications that extend engineering ontologies with reasoning mechanisms. These mechanisms allow two important reasoning tasks: a query capability that facilitates retrieval of existing product data in knowledge base, and an advanced inference capability that allows new product data to be derived through rule extensions. A layered semantic application architecture is proposed. Reasoning units for both assembly level and component level are designed and deployed in this architecture.

Using the methods provided and adding more reasoning units as needed, this semantic application architecture can be easily extended. Test cases successfully demonstrated reasoning tasks that are performed on ontologies at assembly and component levels.

Compared with typical CAD systems, this approach provides a light weight access to

CAD data, which is captured in explicit and formal representations and also provides some inference capabilities that CAD systems cannot provide currently. Thus, the

99

postulated approach to designing semantic applications that add reasoning capabilities to ontologies was successful and shows considerable promise.

9. FUTURE WORK

There are several issues that need to be further investigated based on the present work:

 Improve reasoning capability

The new product data semantics inferred by SWRL/SQWRL rules need to be filtered or improved by integrating more rules or other algorithms. Some SWRL/SWRQL rules in this paper still rely on key terms such as “hole” and “protrusion”. These key terms are expected to be defined formally. Also, more reasoning units for the product engineering domain are being considered to plug in and extend the reasoning capability of the semantic application.

 Allow flexible and customized reasoning tasks

It would be very valuable to implement a custom-made semantic application to serve engineers on various expertise levels considering they have different requirements for the product data. For now, the users are only allowed to choose fixed terms offered by the user interface to make reasoning. Query specifications and inference rules are expected to be generated dynamically according to the user’s inputs. Thus, reasoning tasks will be executed in a more flexible manner.

 Construct a web-based semantic application

The semantic application presented in this paper is local-based. We are working on providing on-line user interfaces to enable engineers to access the knowledge base,

100

which is specifically built for product assembly design domain, across the Internet.

Another paper of ours [43] presents our research in this field.

10. ACKNOWLEDGEMENTS

This work was partially inspired and made possible by ontology modeling and mapping research that was supported by National Science Foundation (NSF) Grant No.

DMI 0523052; the Hubble Telescope assembly and ontology modeling was supported by

NSF Grant#11V3825560/NSF REU Program: DMI. We would like to acknowledge the contribution of Matthew Poppe in creating the Hubble telescope models.

APPENDIX

GLOSSARY OF TERMS

SWRL Semantics Web Rule Language SQWRL Semantic Query-Enhanced Web Rule Language GDO General Domain Ontology DSO Domain Specific Ontology ASO Application Specific Ontology RU Reasoning Unit SQSP SQWRL specification KB Knowledge Base

PROPERTIES OF ONTOLOGIES USED IN THIS PAPER

Property Domain Range Assembly/SubAssem has_component Component bly Existing has_constraint Component Constraint In KB is_assemblyreferenceof Component Constraint is_componentreferenceof Component Constraint has_assemblyref_item Constraint Feature_Element

101

has_componentref_item Constraint Feature_Element has_feature Component Feature Model_Item has_modelitem Feature (≡Feature_Element) has_reference Constraint Component Derived from KB assembleon Component Component assembledwith Component Component

REFERENCES

[1] Horrocks, I., "Description Logic Reasoning”, On the WWW, at

http://www.kde.cs.uni-kassel.de/conf/iccs05/horrocks_iccs05.pdf

[2] Graves, H., 2007, “Ontology Engineering for Product Development”, 3rd OWL:

Experiences and Directions Workshop (OWLED2007)

[3] Matheson, D., 2004, “CAD data model with design notes”, Hewlett-Packard

Company (Palo Alto, CA), 6718218,

http://www.freepatentsonline.com/6718218.html

[4] Koparanova, M. G., Risch T., 2002, "Completing CAD Data Queries for

Visualization," ideas, pp.130, International Database Engineering and Applications

Symposium (IDEAS'02)

[5] Franklin, M. J., Halevy, A. Y., and Maier, D., 2005, “From Databases to

Dataspaces: a New Abstraction for Information Management”, SIGMOD Record,

34(4):27–33

[6] Nicklas, D., Ranganathan, A. and Riboni, D., 2010, “A survey of context modeling

and reasoning techniques”, Pervasive and Mobile Computing,Volume 6, Issue 2,

Pages 161-180

102

[7] Maher, M.L. and Pu, P., 1997, Issues and Applications of Case-Based Reasoning to

Design , Psychology Press

[8] Kulon, J., Broomhead, P. and Mynors, D.J., 2006, “Applying knowledge-based

engineering to traditional manufacturing design”, International Journal of Advanced

Manufacturing Technology 30: 945-951.

[9] Murshed, S.M.M., Dixon, A. and Shah, J.J., 2009, "Neutral Definition and

Recognition of Assembly Features for Legacy System Reverse Engineering", 2009

ASME IDETC/CIE Conference

[10] Meyer, T., “Description Logics for Ontology Reasoning”, On the WWW, at

http://ksg.meraka.org.za/wiki/UKZNHonoursCourse?action=AttachFile&do=get&tar

get=dlcourse-l1.pdf

[11] Berners-Lee, T., Hendler, J. and Lassila, O., 2001, "The Semantic Web", Scientific

American Magazine. Retrieved March 26, 2008.

[12] Aroyo, L., Stash, N., Wang, Y., and Gorgels, P., 2007, “CHIP Demonstrator:

Semantics-driven Recommendations and Museum Tour Generation”, On the WWW,

at http://challenge.semanticweb.org/

[13] Patel, C., Khan, S., and Gomadam, K., 2009, “TrialX: Using semantic technologies

to match patients to relevant clinical trials based on their Personal Health Records”,

On the WWW, at http://challenge.semanticweb.org/

[14] Pisanelli, D.M., 2004, Ontologies in Medicine, Volume 102 Studies In Health

Technology and Informatics, New IOS Publication

103

[15] Rubin, D.L., Dameron, O., Bashir, Y., Grossman, D., Dev, P. and Musen, M.A.,

2006, “Using ontologies linked with geometric models to reason about penetrating

injuries”, Artificial Intelligence in Medicine, Volume 37, Issue 3

[16] Noh,J.D., Suh, H.W. and Lee H.J., 2009, “Hybrid Knowledge Representation and

Reasoning With Ontology and Rules for Product Engineering”, Proceeding of 2009

ASME IDETC/CIE Conference

[17] Crowder, R. M., Wilson, M. L., Fowler D., Shadbold, N., Wills, G. and Wong S,

2009, “Navigation Over a Large Ontology for Industrial Web Applications ”,

Proceeding of 2009 ASME IDETC/CIE Conference

[18] Lim, S. C. J., Liu, Y., and Lee, W. B., 2009, "Faceted Search and Retrieval Based on

Semantically Annotated Product Family Ontology," ACM Workshop on Exploiting

Semantic Annotations in Information Retrieval 2009 (ESAIR '09), The Second ACM

International Conference on Web Search and Data Mining (WSDM 2009), ACM,

Barcelona, Spain.

[19] Li, Z. and Ramani, K. , 2009, “Engineering ontology development and validation for

information retrieval”, Artificial Intelligence for Engineering Design, Analysis and

Manufacturing, Volume 23, Number 1, pages 37-51

[20] Li, Z., and Ramani, K., 2007, “Ontology-based design information extraction and

retrieval,” Journal of Artificial Intelligence for Engineering Design, Analysis and

Manufacturing, 21(2), pp. 137–154

[21] Keller, U., Heymans, S., Reitbauer A. and Neswal, M., 2007, “Spinning a corporate

Semantic Web for Product Engineering”, In Proceedings of the 3rd International

104

Conference on Web Information Systems and Technologies (WEBIST 2007),

Barcelona, Spain

[22] Abdul-Ghafour, S., Ghodous, P., Shariat, B. and Perna, E., 2008,“Towards an

Intelligent CAD Models Sharing Based on Semantic Web Technologies”,

Proceedings of the 15th ISPE International Conference on Concurrent Engineering

(CE2008)

[23] Zhu, L.J., Jayaram, U., Jayaram, S., and Kim, O., 2010, “Querying and Reasoning

with Product Engineering Ontologies – Moving past Modeling ”, 2010 ASME

IDETC/CIE Conference

[24] Zhan, P., Jayaram, U., Jayaram, S., Kim, O. and Zhu, L.J., 2010, "Knowledge

Representation and Ontology Mapping Methods for Product Data in Engineering

Applications", Journal of Computing and Information Science in Engineering, June

2010, Volume 10, Issue 2, 021004

[25] Zhu, L.J., Jayaram, U., Jayaram, S., and Kim, O., 2009, “Ontology-Driven

Integration of CAD/CAE Applications: Strategies and Comparisons”, 2009 ASME

IDETC/CIE Conference

[26] Kim, O., Jayaram,U., Jayaram, S., and Zhu, L.J., 2009, “ITRAIN: Ontology-Based

Integration of Information and Methods in Computer-Based Training (CBT) and

Immersive Training (IMT) for Assembly Simulations”, 2010 ASME IDETC/CIE

Conference

[27] Kim, O., Jayaram, U., Jayaram, S., and Zhu, L.J., 2009, “An Ontology Mapping

Application Using A Shared Ontology Approach and A Bridge Ontology”, 2009

ASME IDETC/CIE Conference.

105

[28] Zhan, P., Jayaram, U., Jayaram, S., Kim, O. and Zhu, L.J., 2008, "Knowledge

Representation and Ontology Mapping Methods for Product Data in Engineering

Applications", 2008 ASME IDETC/CIE Conference.

[29] Zhan, P., Jayaram, U., Jayaram, S., 2007, "A Semantic Approach for CAD/CAE

Integration", Proceedings of 2008 NSF Engineering Research and Innovation

Conference.

[30] Zhan, P., 2007, "An Ontology-Based Approach for Semantic Level Information

Exchange and Integration in Applications for Product Lifecycle Management",

Dissertation, Washington State University, Pullman, Washington.

[31] Baader,F., Calvanese, D., Mcguinness, D.L., Nardi, D., and Patel-Schneider, P.F.,

2007, The Description Logic Handbook , Cambridge University Press

[32] Gordon, T.F., Governatori, G. and Rotolo, A., 2009, “Rules and Norms:

Requirements for Rule Interchange Languages in the Legal Domain”, Rule

Interchange and Applications , Springer, Berlin Heidelberg. See also URL

http://www.springerlink.com/content/v81q672j251ln864/fulltext.pdf

[33] W3C, 2004, “SPARQL Query Language for RDF”, On the WWW, at

http://www.w3.org/TR/rdf-sparql-query/

[34] ProtegeWiki, “SQWRL”, On the WWW, at http://protege.cim3.net/cgi-

bin/wiki.pl?SQWRL

[35] O’Connor, M., Das, A., 2009, “SQWRL: a Query Language for OWL”, Proceedings

of OWL: Experience and Directions 2009(OWLED 2009).

[36] Clark&Parsia, “Pellet: OWL 2 Reasoner for Java”, On the WWW, at

http://clarkparsia.com/pellet

106

[37] Obitko, 2007, “Introduction to Ontologies and Semantic Web”, On the WWW, at

http://www.obitko.com/tutorials/ontologies-semantic-web/introduction.html

[38] Dickinson, I., “Jena Ontology API”, On the WWW, at

http://jena.sourceforge.net/ontology/index.html

[39] Stanford Center for Biomedical Informatics Research, On the WWW, at

http://protege.stanford.edu/overview/protege-owl.html

[40] Sandia National Laboratories,“JESS, the Rule Engine for the Java Platform”, On the

WWW, at http://www.jessrules.com/jess/index.shtml

[41] Jayaram, U., Kim, Y., Jayaram, S., Jandhyala, K., and Mitsui, T.,2004,

"Reorganizing CAD Assembly Models (as-designed) for Manufacturing Simulations

and Planning," Journal of Computing and Information Science in Engineering, 4(2),

pp. 98-108

[42] Parametric Technology Corporation, 2008, PRO/ENGINEER® Wildfire® 4.0 J-Link

User’s Guide

[43] Zhu, L.J., Jayaram,U. and Kim, O., 2011, “Online Semantic Knowledge

Management for Product Design Based on Product Engineering

Ontologies”, 2011 ASME IDETC/CIE Conference

107

Chapter Five - Online Semantic Knowledge Management for

Product Design Based on Product Engineering Ontologies

ABSTRACT

The influence of the Semantic Web is growing in many areas. In this paper, the authors present an online Product Design Semantic Knowledge Management System

(PD-SKMS) in order to provide a novel approach for presenting, querying/reasoning, and authoring/updating knowledge related to product design in engineering domains. A distributed model is proposed, which is composed of a Host Hybrid-Data Repository

(HDR), external public linked data sources (EPLD), a Semantic Data Management

Engine (SDME), and a web-based user interface layer. Ontologies to preserve knowledge for the product assembly domain are set up as Product Semantic Repositories (PSR) in

Host Hybrid-Data Repository. To utilize the legacy design information, a conventional

Product DataBase (PDB) storing design data is also integrated into HDR. SDME is able to supply querying/reasoning and authoring/updating services on PSRs, as well as searching and updating services on PDB. Through web-based user interfaces, engineers on the Web can inquire/contribute design information/knowledge from/to both PSR and

PDB. Additionally, the capability of PD-SKMS is extended by querying on external public linked data sources. It is concluded that the product design environment, constructed on PD-SKMS, allows more knowledge questioners/contributors to be involved into product design tasks in a more interactive manner, and thus greatly improves traditional behaviors for design knowledge sharing and exchanging.

108

Keywords: Product Design, Semantic Web, Linked Data, Knowledge

Management, Engineering Ontology, Ontology Query/Reasoning, SPARQL, Exhibit,

JSON

INTRODUCTION

CAD automation has greatly improved productivity in engineering domain. There is a tremendous volume and diversity of product design data that engineers now create through the use of better and more automated design tools. However this data needs to be managed, controlled, updated, and shared efficiently to gain a competitive edge, especially in today’s distributed work environment. Innovative approaches adopting new technologies are required to satisfy these requirements.

Ontology-based approaches have been researched recently for managing heterogeneous product data. This is because ontology-based models allows engineers in a specific domain to represent design knowledge in a relatively flexible manner along with a formal and machine manipulatable standard in a context dependent way.

However, building these ontology models is just the first step for setting up an innovative product design environment. In order to realize the full potential of ontologies and create knowledge-contextual design environments, we need to exploit product design knowledge that has been captured in ontology models by extending the scope of sharing and reusing of these ontologies. In addition, today many engineers are interested/ willing to provide design knowledge or find answers on the Web, and they are distributed globally. The old assumption that a single user would interact with a system characterized by a centralized local knowledge base is out of date and needs to be revisited and addressed with the advent of the Web (Gil, 2011) .

109

The Semantic Web provides a common framework that allows data to be shared

and reused across application, enterprise, and community boundaries (W3C, 2009) .

Currently Semantic Web applications are used for management of personal information,

travel planning and data in telecommunication, legal domain (John, Marko & Dunja, 2008) ,

defense and intelligence, including sensor and social computing (Sheth, 2010). Howev er, very few Semantic Web applications have been developed for the product design in

engineering domain.

This research aims to explore an online Product Design Semantic Knowledge

Management System (PD-SKMS) and realize a knowledge-contextual design

environment by integrating design knowledge with Semantic Web technologies. This

paper is organized as follows: firstly, the background of this research is introduced; next,

Semantic Web technologies adopted by this paper are summarized; and then the

motivation and underlying architecture of PD-SKMS is discussed followed by the details

of components deployed in PD-SKMS; test scenarios are then illustrated to demonstrate

PD-SKMS; finally, conclusion and further work are presented.

LITERATURE REVIEW AND BACKGROUND

Semantic Web and Public Linked Data

The Semantic Web is an evolution of World Wide Web which enables machines

to understand, analyze the requests of end-user, communicate with each other, and

perform more of the tedious work such as finding, sharing, and combining information on

the web (Wikipedia: Semantic Web, 2011).

The key of Semantic Web is using semantics to represent, combine, and share

knowledge between communities of machines. Applications allowing users to make

110

connections and understand relationships that were previously hidden are very powerful and compelling. But currently, because of the hidden nature of data on the Web, the process to build these applications usually depends on hand-tuned and ad-hoc techniques to integrate information (Segaran, Evans & Taylor, 2009). Using the description languages, such as Resource Description Framework (RDF) and Web Ontology

Language (OWL), standards of Semantic Web, data can be made explicit with the semantic relationships, and thus computer systems are allowed to change data based on the meaning of the data.

The above characteristic of Semantic Web makes it possible for the Semantic

Web to integrate data from different sources which are using different schemas. Linked

Data refers to a set of best practices for publishing and connecting structured data on the

Web (Wikipedia: Linked Data, 2011). Numerous individuals and groups can publish

Linked Data and contribute to the building of a Web of Data, which lowers the barrier to reuse, integrate and apply data from multiple, distributed and heterogeneous sources

(Watson, 2010). There are already many useful public Linked Data sources existing, such as DBpedia, Freebase, FOAF and so on. In addition, an approach for a seamless integration of these linked data sets based on an upper level ontology is addressed (Jain,

P., Hitzler, P., Yeh, P. Z., Verma, K., & Sheth, A. P., 2009).

Knowledge-based System for Engineering Domain

A knowledge-based system can support creative design in various ways such as by providing better user interfaces, bigger knowledge bases, better knowledge representations, and a computational model with flexible search mechanism (Gero &

Maher, 1993).

111

A common approach to capturing and storing product data from design tools employs database technologies. For example, systems permitting database queries over data extracted from a CAD system have been developed (Koparanova and Risch, 2002).

However, the external query system outside the CAD system must be transferred to standardized data exchanging formats for interoperating with CAD systems. Therefore, traditional database systems are not applicable for data management involving heterogeneous but interrelated data, because not all the data can be fit conveniently into a very structured format of database system (Frankin, Halevy & Maier, 2005). Also, database systems can’t provide an environment for semi-automatically creating relationships or improving and maintaining existing relationships between data.

As one of approaches supporting knowledge capturing and reasoning for engineering analysis and design tasks, context based modeling approaches (CML)

(Nicklas, Ranganathan & Riboni, 2010) doesn’t provide the support for interoperability since it emphasizes the development of context models for particular applications or application domains. In recent years, neutral definitions based on STEP and ISO

EXPRESS (Murshed, Dixon & Shah, 2009) have been used to capture product data in engineering domain. But the EXPRESS schema language lacks extensibility. Traditional rule-based expert systems put an emphasis more on implementing technologies than on the knowledge itself (Welty, 1999) and the old expert systems are monolithic, and computer-centric. Modern ontology-driven expert system is expected to make raw knowledge programmable and enable the domain expert to be a good “communicator” who shares knowledge/expertise (Morris, 2008).

112

In the product engineering domain, a large amount of product information is described through design documents for user requirements, customer dialogs, survey reports, etc. Often the concepts of customer preferences are implicit within these documents (Li, Raskin & Ramani, 2008). Eliciting and extracting this information is essential to achieve success in product development (Cao, Ramani & Liu, 2010). An approach has been introduced to identify influential relationships using ontology alignment and semantic relatedness techniques in order to improve knowledge management in product development processes (Witherell, Krishnamurty, Grosse &

Wileden, 2009).

It is believed that ontologies will be broadly adopted and integrated into knowledge/information management system for engineering domains by engineering community.

Online Semantic Tool for Engineering Domain

Past approaches for knowledge representation and retrieval are outdated and ineffective in today’s climate of computer-based social networking and computational literacy. Large communities on the Web, such as Facebook, Flickr, LinkedIn and Twitter, demontrate that individuals are increasingly collaborating over the Internet in very large numbers. It will be significant to create an online system that links engineers in a more professional setting with the ability to share non-proprietary models and information as well as to provide opportunities to trouble shoot problems.

There are numerous efforts in the product engineering domain using Internet technology. In order to use Semantic Web technologies for the automation of E-Business tasks, domain ontologies for products and services. This research yielded a fully-fledged

113

ontology for the product and services domain, reflecting more than 25,000 product types in 75,000 ontology classes (Hepp, 2006). The author further proposed ontology, named

GoodRelations, that satisfies representational needs in e-commerce scenarios (Hepp,

2008; Hepp, M. & Radinger, A., 2010). However, GoodRelations puts more attentions to business domain, e.g. product price and company data, instead of product design domain.

A design repository was created to enable storage and retrieval of design artifact knowledge via a web interface (Szykman, Sriram, Bochenek, Racz & Senfaute, 2000).

But this work didn’t take full advantage of semantic technologies. The STEP module using XML can be rendered dynamically in a Web browser in response to user input and be independent of an HTTP server (NIST, 2002). Semantic Wikis has been used to form a central knowledge base for semantic search engine which performs computational fluid dynamics simulations and assists airfoil design (Fowler & Crowder, 2010). The semantic tools provided by the EU-funded WIDE project supports innovative product design in the automotive field (Sevilmis & Stork, 2005). Currently, Semantic Web technologies, tools and standards are adopted for information retrieval in multi-disciplinary activities.

There are still very few online semantic tools developed and published for the engineering domains. More effort needs to be spent in this area and research work is expected to bring the Semantic Web technologies into the product development process in a more concrete form.

Our Previous Work

In our previous work, we have designed and implemented rich ontology models for the product design domain (Zhan, Jayaram, Kim & Zhu, 2010, 2008, 2007; Zhu,

Jayaram & Kim, 2009; Kim, Jayaram & Zhu, 2010, 2009; Zhan & Jayaram, 2007; Zhan,

114

2007). Further, we exploited and extended the semantic representation with reasoning

mechanisms (Zhu, Jayaram & Kim, 2010), which makes two important tasks possible:

firstly, query and retrieve existing product data information and secondly, through rule

definitions, derive new product data information that is not explicitly expressed in

information models. All we have done sets up a solid base for the current research.

This paper investigates the applicability of the Semantic Web technologies to product

design in the engineering domain. There are four significant contributions of this paper

that differentiate it from other researches in this domain:

• Construction of a knowledge-contextual design environment based on semantic knowledge management;

• Capability to query/reason and author/update on a host hybrid-data repository;

• Creation of a novel approach to present product data semantics through the Web;

• Extension of knowledge by linking to external public linked data sources.

SEMANTIC WEB TECHNOLOGIES

Semantic Web is a group of methods and technologies to allow machines to understand the meaning of data. It comprises of standards such as XML, RDF, RDF

Schema and OWL, all of which are organized in the Semantic Web Stack (Wikipedia,

2010), as shown in Figure 1.

115

Figure 5 - 1: Semantic Web Stack (Wikipedia, 2010)

RDF is a simple language for expressing data models, which represents objects

("resources ") and their relationships. RDF Schema extends RDF. OWL adds more vocabulary for describing properties and classes.

SPARQL (W3C, 2007) stands for SPARQL Protocol and RDF Query Language and it can make queries on semantic web data sources. SPARQL is considered a key semantic web technology. It can be utilized to identify data quality problems in Semantic

Web (Fürber, C. & Hepp, M., 2010). Table 1 shows a SPARQL SELECT query example for the product design domain. This query will find out all assemblies containing sub components which have volume greater than 1000 cm 3 in a product design domain ontology (PRO-AO):

116

SPARQL SELECT Query Example: SPARQL0 PREFIX PRO-AO: SELECT ?assembly ?subcomponent ?volume WHERE { ?assembly PRO-AD: has_component ?subcomponent . ?subcomponent PRO-AD: has_volume ?volume . FILTER (? volume > 1000) . } ORDER BY ?assembly ?volume

Table 5 - 1: SPARQL Example for Product Design Domain

Since SPARQL is widely supported by the development community of Semantic

Web, the work in this paper also adopts it as the query language for semantic data.

PRODUCT DESIGN SEMANTIC KNOWLEDGE MANAGEMENT SYSTEM

(PD-SKMS)

The development of PD-SKMS is motivated by the practical requirements from the real world. Accordingly, this section will first discuss the practical requirements in product design domain, and then put forward the objectives and underlying architecture of PD-SKMS.

Requirements for PD-SKMS

As discussed in Introduction section, product development teams face challenges in sharing and reusing dramatically large amounts of product data nowadays. Thus, principally, PD-SKMS seeks to manage, control, and share the large amounts of product design data through the use of Semantic Web technologies.

117

Consider the situation of an engineer performing a design task for a product. The

design activities can be approximately divided into three stages. In the initial stage,

he/she most probably would search and refer to the existing design data for the same or

similar products. Considering the influx of information on Internet today, it is very tough

to find out really relevant product data. However, since PD-SKMS is designed

specifically for product design domain, it is much easier for him/her to discover the

relevant product information. In the second stage, while reusing the product data obtained

from the first stage to design his/her own product, frequently, this engineer may search

and make queries/reasoning on PD-SKMS to clarify/identify some design details. Finally,

after this engineer finishes the design successfully, he/she may contribute the design

expertise to public in order to help other engineers later. Figure 2 shows the design

process yielding requirements for PD-SKMS.

Figure 5 - 2: Design Process Yields Requirements for PD-SKMS

Hence, this online PD-SKMS, which manages product design data/knowledge, should enable practicing engineers to a) present queries and requests for design tasks and

118

b) input their opinions/expertise for design problems, and thus allow them to stay actively

connected with colleagues as well as updated with new design information.

Objectives of PD-SKMS

The fundamental objective of this paper is to propose a model that enables

semantic knowledge management for product design in engineering domain. Based on

the requirements in the previous section, the basic functionalities of this system include:

• Be able to access and integrate heterogeneous data across host semantic repositories,

host rational databases and external public linked data;

• Be able to provide querying/reasoning as well as authoring/updating services on the

hybrid-data repository for engineers on the Web according to authentications assigned to

them;

• Be able to visualize and manifest semantic data with multiple views. These data being displaying will come from disparate data sources.

Underlying Architecture of PD-SKMS

A distributed model is proposed in Figure 3. The components of this architecture include:

• Host Hybrid-Data Repository (HDR)

• External Public Linked Data (EPLD)

• Semantic Data Management Engine (SDME)

• Web-based User Interfaces

HDR and SDME reside on a host server in VRCIM lab at Washington State

University while EPLD is composed of public data sources residing on external servers.

119

Engineers on the Web can access the Web -based user interfaces with Web browsers on any client machine.

Figure 5- 3: Underlying Architecture of PD-SKMS

HDR consists of Product Semantic Repositories (PSR) capturing design knowledge for the product design domain, and a conventional Product DataBase (PDB) storing legacy design data.

SDME supplies querying/reasoning and authoring/updating services on PSRs, searching and updating services on PDB as well as querying service on external public linked data.

Through Web-based user interfaces, engineers can inquire/contribute design information/knowledge from/to PSRs and PDB and also query relevant information from external public linked data sources. The querying results from all these disparate data sources will be combined and displayed in Web -based user interfaces.

The details of these components will be explained in the following section.

120

COMPONENTS DEPLOYED IN PD-SKMS

This section will explain the components of PD-SKMS roughly following the order of development process, which can be listed as: building Host Hybrid-Data

Repository, developing Semantic Data Management Engine, visualizing semantic data and linking to external public linked data.

Host Hybrid-Data Repository (HDR)

As introduced in previous sections, semantic repositories and a relational database are built into HDR.

Product Semantic Repository (PSR)

In previous work, we built ontologies based on a 3-layered structure: 1) General

Domain Ontology (GDO); 2) Domain Specific Ontology (DSO); 3) Application Specific

Ontology (ASO). ASO is built on DSO and GDO while DSO is built on GDO. ASOs are built for design tools/applications: 1) PRO-AO: PRO/E Application Ontology; 2) CAT-

AO: CATIA Application Ontology; 3) VADE-AO: VADE Application Ontology. PRO-

AO and CAT-AO fall under the same domain of Product Design Domain (PDD).

In this paper, the semantic repository is designed as storage for the ontology models in Product Design Domain, e.g. PRO-AOs, which capture product data semantics from PRO/E models such as Hubble Telescope, wind turbine, etc.

However, there is one problem emerging: how to store and manage these ontologies in a semantic repository. There are two methods to handle this problem: a) store PRO-AOs in the server as usual local files; b) use an independent database to store

PRO-AOs. Obviously, the second method is better considering the independent database

121

is able to manage numerous ontology models efficiently and supply uniform APIs to other applications, e.g. ones searching and accessing the data from it while the first method is inflexible and limited for a Web application development.

Sesame (openRDF, 2010) is an open source Java framework for storing, querying and reasoning with RDF(S) and it provides the necessary tools to parse, interpret, and query RDF(S). As a plug-in, OWLIM (ontotext, 2011) is a high-performance Storage and

Inference Layer (SAIL) for Sesame and it partially supports OWL. OWLIM is based on a native RDF rule-entailment engine and the supported semantics can be configured through the definition of custom rule-sets. Currently, OWLIM is the fastest OWL- supported repository available.

Sesame supports remote access through HTTP connection, and several query languages including SPARQL. In our approach, administrator engineers on the Web are allowed to add, delete and manage semantic data stored in Sesame remotely through a

Web-based interface (Code 1 in Table 2). A local-based tool is also developed to help administrator manage PSR locally (Code 2 in Table 2).

Code 1: Remote Access(HTTP Connection) String sesameServer = "http://134.121.72.137:8080/openrdf-sesame"; if(kb.equals("HubbleTelescope")) repositoryID = "HUBBLEWITHRULE"; Repository myRepository = new HTTPRepository(sesameServer, repositoryID); myRepository.initialize(); RepositoryConnection con = myRepository.getConnection(); … Code 2: Local Management(Add a local owl file, a namespace to product semantic repository) File owlfile = new File("F:\\Eclipse\\SesameApp\\data\\PRO- AO_InsofSUM_SWRL.owl"); String baseURI = "http://www.wsu.edu/vrcim-onto/PRO-AO.owl"; con.add(owlfile, baseURI, RDFFormat.RDFXML); … URL GDO = new URL("http://www.wsu.edu/vrcim-onto/GDO.owl#"); con.add(GDO, GDO.toString(), RDFFormat.RDFXML);

Table 5 - 2 : Two Approaches to Access PSR

122

Figure 4 illustrates the interior organization of PSR.

Figure 5 - 4: Organization of Product Semantic Repository

Product database (PDB)

There are two reasons to integrate a relational database into HDR. Firstly, as a conventional approach to capturing and storing product data from design tools, relational databases are storing a large amount of valuable legacy design data, e.g. information related to CAD models, design rules as well as their interdependencies on material, production unit, and manufacturer capabilities, etc. It will be a big loss if all this information cannot be utilized.

Secondly, the database will be used to organize and store queries, comments, external materials sources, e.g. videos, documents and CAD models, etc., which may be provided by engineers through the Web.

Table 3 lists some schemas and tables included in PDB currently:

Schema Table Column Id, pname, length, weight, maxdiameter, Basic-parameter hubbledb speed, accuracy, power, startdate Imglib Id, imgname, sourcefile, type, description Doclib Id, docname, sourcefile, type, description Vediolib Id, vedioname, sourcefile, type, description wind- Comments Id, author, content, topic, postdate turbinedb Queries Id, author, content, topic, postdate

Table 5 - 3: Structure of PDB

123

Integration of PSR and PDB

In PD-SKMS, the semantic repository storing ontology models works together with a conventional database.

In point of fact, we believe the semantic repository cannot replace the databases at this time. Firstly, although some approaches are offered to convert typical relational data into RDF, the conversion is still a challenging job. Secondly, the usage of semantic representation is still restricted in some ways. It is true that semantic repository is more appropriate for sparse data representations. For example, in ontology models, it is flexible to define new properties between existing concepts and then use these properties to make statements on existing resources. However, not every user on the Web is willing/used to reorganize his/her thinking with concepts, properties in a ontology-way. Most of them incline to the natural language, which is informal and unstructured.

Hence, in PD-SKMS, a database is used to store all inputs from engineers in addition to providing legacy design data. Some of inputs, about design expertise, rules, etc. will be stored in PDB first, then be processed and translated to knowledge representation, e.g. ontology in OWL, and finally captured into PSR. The processing and translating work will not be discussed in this paper and it will be one objective of PD-

SKMS in the future.

SEMANTIC DATA MANAGEMENT ENGINE (SDME)

Information is only valuable if it can be found readily for the right purpose.

Figure 5 shows the functionalities of SDME. As discussed in previous section, two kinds of back ends are supported by SDME: PSR and PDB. Through querying and reasoning on PSR, the engineers are able to access product data semantics/design

124

knowledge capture d in product design domain ontologies; through querying on PDB, they can get related design information/materials from product database. The SPARQL query language is used to access semantic data in PSR while SQL is used to access data in PDB.

Figure 5 - 5 : Functionality of SDME

Querying/Reasoning on PSR

The engineer might need the following information from an assembly product:

a) Components of this assembly;

b) Details of component, including name, volume, materials, etc. ;

c) Constraint information for every component;

d) Details of constraint, including assembly reference, component reference, etc.;

e) Internal relationship between components;

f) Geometry attributes of constraint reference, etc.

Querying: The existing p roduct data semantics can be retrieved by direct querying on PSR. For example, information a), b), c) and d) are explicitly captured in

PRO-AOs, so they can be retrieved out by SPARQL1 and SPARQL2 (Table 4) from

PSR.

125

 SPARQL1: retrieve product data for a), b) and c)

There are two types of component are defined in PRO-AO: Part and

SubAssembly . SubAssembly is different from Part because it is composed of Part .

Part and SubAssembly have some common property, such as has _name, has _constraint , etc., but property has_component is appropriate for SubAssembly , not for Part while property has_volume is appropriate for Part , not for SubAssembly

(This is because the volume was captured for Part , but not for SubAssembly ). Hence,

SPARQL1 queries Part and SubAssembly , respectively, and return the union of the two result sets. Here OPTIONAL means to retrieve the constraint information for a component if this component has constraints. In this way, the base component of an assembly will also be included in the final result set.

 SPARQL2: retrieve product data for d)

This query returns assembly reference, assembly reference model item, component reference and component model item for one constraint.

126

SPARQL SELECT Query on PSR: SPQRQL1 for a), b) and c) SELECT * WHERE { { ?component rdf:type ?class . ?class rdfs:subClassOf PRO-AO:Component . ?component PRO-AO:has_name ?name . ?component PRO-AO:has_volume ?volume . OPTIONAL {?component PRO-AO:has_constraint ?constraint ?constraint PRO-AO:has_assemblyreference ?assembleto .}

} UNION { ?component rdf:type ?class . ?class rdfs:subClassOf PRO-AO:Component . ?component PRO-AO:has_name ?name . ?component PRO-AO:has_component ?subcomponent . OPTIONAL {?component PRO-AO:has_constraint ?constraint . ?constraint PRO-AO:has_assemblyreference ?assembleto .} } } ORDER BY ?component SPARQL SELECT Query on PSR: SPQRQL2 for d) SELECT * WHERE { ?labelconstraint PRO-AO:has_assemblyreference ?assemblyreference . ?labelconstraint PRO-AO:has_assemblyref_item ?arefitem . ?labelconstraint PRO-AO:has_componentreference ?componentreference. ?labelconstraint PRO-AO:has_componentref_item ?crefitem . }

Table 5 - 4: SPARQL Queries for a), b), c) & d)

Two SPARQL queries are given as examples in this section. These can be easily extended to retrieve other product data semantics.

Reasoning: New product data semantics not explicitly represented in ontologies can be inferred by make reasoning on existing product data semantics through rule definitions. Ontology is different from database, programming languages or other modeling tools because it is built on a logic base, which enables the explicit, formal declaration of information models and hence supports inferences by logical rules. We have published/submitted other papers (Zhu, Jayaram & Kim, 2010) which discuss ontology reasoning with SWRL/SQWRL in detailed.

Since PSR in PD-SKMS is built on OWLIM, which is based on a native RDF rule-entailment engine, some custom rule-sets have been defined for OWLIM to realize the inference.

127

For example, information e) and f) cannot be retrieved out directly from PRO-

AOs since they are not explicitly represented. However, with following rules, they can be inferred from the existing product data semantics.

 RuleSet1: This rule set infers the internal relationship between two

components.

We believe that the more closely two components are related, the more

probable that their design parameters are interrelated. Two components are regarded

closely related if:

• myrule1: they are assembled directly with some constraints;

• myrule2: they are connected by another component

For the large-scale assemblies, this rule set will make it much easier to figure

out the internal relationships between components.

SPARQL3 takes advantage of inferences by RuleSet1 and returns the

components closely related ( assembleon and assembledwith ) to one component.

Ruleset1 for e) Id: myrule1 x y y z ------x z

Id: myrule2 x y y z ------x z

SPARQL SELECT Query on PSR: SPQRQL3 SELECT * WHERE { {?x PRO-AO:assembleon ?y .} UNION {?x PRO-AO:assembledwith ?z . }}

Table 5 - 5: Reasoning for e)

128

 RuleSet2:

In PRO-AOs, the exact type of model item referenced by a constraint isn’t

captured. For example, the model items referenced by Mate are captured as instances

of Surface , but the fact that these surfaces are planar or cylindrical is unknown.

RuleSet2 can help infer the exact type of these surfaces. As examples, two rules for

Mate are given, which can infer the surfaces referenced by Mate are planar. Other

rules for Insert and Align are also defined in this rule set.

Ruleset2 for f) Id: myrule3 x y x y ------y

Id: myrule4 x y x y ------y

Table 5 - 6: Reasoning for f)

Here just two rule sets are given as examples. What we hope is demonstrated that more rules can be defined into SDME and help to derive new product data semantics.

Authoring/Updating on PSR

It is important that engineers can contribute his/her design expertise/knowledge to

PSR as well as inquire design data/knowledge from it.

The Web world is so powerful because it not only presents information but also provides an open environment for anyone interested to get involved and contribute.

Without many restrictions, everyone can convey, publish and contribute his/her opinions/knowledge on the Web and reach other people. For the product design domain,

129

if there is an online system allowing more and more engineers to contribute their experience/knowledge to the public, we believe engineers all of the world will be benefitted greatly and this will help accelerate and improve the product design process.

Knowledge grows more if it is shared.

However, as discussed in Section 5.1, human users are used to expressing thoughts in natural language, which is informal and unstructured. It is not easy to translate this information into formal and structured design knowledge. The processing and translating work will be one objective of PD-SKMS in the future.

Currently, SDME is implementing the instantiation and update for PSR by RDF manipulations. That means the engineers will be allowed to input the information in a pattern like: Subject-Predicate-Object.

For example, an engineer inputs: a) MirrorTruss as Subject ; b) has_material as

Predicate ; c) Aluminum as Object in a given user interface. The statement: MirrorTruss

(Subject) has_material (Predicate) Aluminum (Object) will be created and added/removed to/from the semantic repository by the following code.

Code 3 for RDF manipulation Graph myGraph = myRepository.getGraph(); ValueFactory myFactory = myGraph.getValueFactory(); String namespace = " http://www.wsu.edu/vrcim-onto/PRO-AO.owl#”; URI Subject = myFactory.createURI(namespace, "MirrorTruss"); URI myPredicate = myFactory.createURI(namespace, "has_material"); Literal myObject = myFactory.createLiteral("Aluminum "); myGraph.add(mySubject, myPredicate, myObject); … myRepository.addGraph(myGraph); myRepository.removeGraph(myGraph);

Table 5 - 7: Authoring/Updating on PSR

130

Searching and Updating on PDB

The technologies for searching and updating conventional databases are much

more mature. Through PDB in PD-SKMS, an engineer would get legacy design data,

related design materials such as videos, images, documents, etc. Moreover, he/she will be

allowed to upload these materials. Queries, comments from engineers are also stored in

PDB and are available to check later. The following code connects the MySQL database:

hubbledb, select a document, named ” Hubble_Space_Telescope_Expert_Model ” from

Doclib table (Table 3) and insert a comment to Comments table.

Code 4 for SQL String url = "jdbc:mysql://134.121.72.137:3306/hubbledb"; con = DriverManager.getConnection(url, "root", "vrcim"); … String query_str = “SELECT * FROM Doclib where docname = 'Hubble_Space_Telescope_Expert_Model’”; PreparedStatement ps = con.prepareStatement(query_str); ResultSet rs = ps.executeQuery(); … String insert_str = "insert into comments (Id, author, content, topic, postdate) values (?, ?, ?, ?, ?)"; … ps = con.prepareStatement(insert_str); ps.executeUpdate();

Table 5 - 8: Searching and Updating on PDB

VISUALIZE SEMANTIC DATA

Until now, we have focused on knowledge representation and knowledge querying/reasoning. The next key consideration is knowledge presentation and visualization. There is no doubt that a good presentation of knowledge will bring better user experience, improves knowledge understanding and make tacit knowledge more explicit. One contribution of this paper is providing a novel approach to present product data semantics through the Web.

131

From the existing frameworks for publishing structured data, PD -SKMS chooses

Exhibit as the visualizing tool for product semantic data. Exhibit (Huynh, Karger &

Miller) is a lightweigh t framework for publishing structured data on standard web servers. It allows creators to publish richly interactive pages and exploit the structure of data for better browsing and visualization.

Figure 6 shows the visualization process for query results from SDME.

Figure 5 - 6: Visualization for Query/Reasoning Results from SDME (incomplete)

Each time after executing SPARQL for querying or reasoning tasks, SDME will return a list of tuples . Here a JSON Translator has been developed in PD -SKMS to translate these tuples into JSON (JavaScript Object Notation), which is Exhibit’s native format. Most Exhibit applications published on Web present the static data which is created before presenting and cannot be changed during presenting. Different from these applications, PD-SKMS presents dynamic semantic data changing along with the different query/reasoning tasks.

The first segment in Table 9 is the JSON data converted from querying results of

SP ARQL1 (Table 4) using JSON Translator; the second segment shows the way to integrate Exhibit with JSON data into a Web -based user interface. In the next section, the web-based user interfaces containing rich, dynamic visualizations of product data semantic s by aid of Exhibit will be shown.

132

Segment of JSON data for querying results of SPQRQL1: { component:"HUBBLE_BOTTOMCIRCULARHANDLE168_HUBBLE_A SSEMBLY", label:"HUBBLE_BOTTOMCIRCULARHANDLE168_HUBBLE_ASSEMB LY", name:"HUBBLE_BOTTOMCIRCULARHANDLE", type:"Component", subtype:"Part", constraint:"Align_Offset11", assembleto:"HUBBLE_BASE18_HUBBLE_ASSEMBLY", volume:"283.23", domain:"http://www.wsu.edu/vrcim-onto/PRO-AO.owl#HubbleTelescope", author:"VRCIM Lab@WSU" }, … Segment of HTML for presenting query results with Exhibit

Table 5 - 9: JSON Data Inlined in Exhibit

LINK TO EXTERNAL PUBLIC LINKED DATA (EPLD)

Linking data resources in RDF can extend the web so that both human and software agents can use these data resources. By querying EPLD deployed in PD-SKMS, the engineers may get in-depth linked design information from these public resources.

Currently, two public linked data sources are selected for EPLD: a) DBpedia

(2007) which contains the RDF information that points to and categorizes data contained in Wikipedia, and b) Freebase (2007): a community driven web portal that allows people to enter facts as structured data. For now, PD-SKMS scrapes DBpedia and Freebase with keyword searching by calling the Web services supported by these two data sources.

Code 5 for linking to Freebase String keyword = request.getParameter("keyword"); Freebase sandbox = Freebase.getFreebaseSandbox(); JSON result = sandbox.search(keyword); …

Since the querying results from both data sources are structured data (XML from

DBpedia and JSON from Freebase), Exhibit is still capable to visualize these results.

133

Linking to EPLD is expected to extend the querying capability of PD -SKMS and supply broader horizons for the engineers. Actually, PD -SKMS runs on the semantic data, which is specifically for the product design domain. Once the semantic data of PD -

SKMS is p ublished on the Web, it provides linking service to other Semantic Web applications.

Figure 7 gives a complete visualization process for semantic data obtained by

SDME.

Figure 5 - 7 : Visualization for Retrievals fr om SDME (complete)

DETAILED EXAMPLE OF PD-SKMS

Design Task: Hubble Telescope

As a test case, PD-SKMS has been set up as a design environment for a Hubble

Telescope related design exercise. The Hubble Telescope (Figure8.I) is the first space - based telescope in the world which collects various images from space. Since the telescope has been used since 1990, some components needed to be repaired or redesigned in order to improve the quality of image sent back to E arth. The simplified assembly model in PRO/E (Figure8.II) includes 47 parts and 4 sub -assemblies.

134

Specifically, Figure8.III shows the optical system of Hubble Telescope , which consists of two mirrors, support trusses and the apertures (openings) of the instruments.

The Hubble telescope was a good candidate for our work since: firstly, we have finished the modeling work for Hubble Telescope assembly supported by a NSF Grant and some design data have been kept in a conventional database; secondly, there are many fans with engineering background who are interested in this famous telescope and may be motivated to design their own telescopes someday. However, the resources that have been published for Hubble Telescope , especially information about design parameters, e.g. dimensions of every component, are currently limited from the Web.

Figure 5 - 8 : Example Hubble Telescope Assembly

Hence, this PD-SKMS intends to provide a knowledge-contextual design environment for engineers who are looking for the design information/knowledge of a telescope. Specifically, this system will tie together different kinds of data to show that semantic data management makes the design task much easier by exploiting product data semantics with extensible and sophisticated queries. The capabilities include:

• Inquire product data semantics of Hubble Telescope assembly

• Inquire legacy design data of Hubble Telescope assembly by searching on PDB

• Inquire related information about Hubble Telescope by querying EPLD;

135

• Contribute design information/knowledge by updating on PDB and authoring/updating on PSR (which is in progress now);

• Virtualize and manifest semantic data with multiple views.

The schematic of the main Web-based user interface for PD-SKMS is given in

Figure 9. This user interface provides entries to PSR, PDB and EPLD for engineers. The administrator can also access and manage PSR through the Web-based tool supported by

Sesame.

Figure 5 - 9: Schematic of Main Web-based User Interface for PD-SKMS

Toolkits

Table 10 just lists the toolkits adopted in the development of PD-SKMS without introductions, considering some key toolkits have been introduced in previous sections.

Component in PD-SKMS Toolkit PSR Sesame, OWLIM, Tomcat PDB MySQL Sesame API+SPARQL, SDME SQL+JDBC, Java Servelt Web-based User Interface JSP, Javascript, Exhibit

Table 5 - 10 : Toolkits Adopted by PD-SKMS

136

Scenario 1: Query on PSR and PDB and Exhibit Product Data Semantics

In this scenario, SDME will execute SPQRQL1 and SPQRQL2. The query results including: a) components of Hubble Telescope assembly; b) details of component, including name, volume, materials, etc.; c) constraint information for every component; d) details of constraint, including assembly reference, component reference, etc. will be retrieved out without accessing CAD systems once the product data has been captured into PRO-AO.

The retrieved semantic data are presented in Figure 10 and Figure 11 u sing

Exhibit technology which provides several ways to display the structured data.

Figure 5 - 10 : Present Product Data Semantics for Hubble Telescope Assembly -I:

Thumbnail

In Pane 1 of Figure 10, the semantic data are classified according to their types

(Facet ). For example, all instances of Component are listed in the facet of Component .

137

Pane2 of Figure 10 shows all components (51 in total, including Part and SubAssembly )

of Hubble Telescope assembly with a thumbnail view. And these components are sorted

by their volumes in this view.

Figure 11 presents the same retrieved product data in a tabular view. As a result,

the relationships between data are easy to be identified. We can read the name, type,

volume, subcomponent, constraint, etc. for every component. As shown in this figure,

different colors are also used to categorize the type of component. For example,

SubAssembly is colored in orange while Part is colored in yellow. In addition, the semantic data can be displayed dynamically. For example, by clicking any constraint, e.g.

Insert1, a mini window will pop up to display the details of this constraint. This dynamic character brings much convenience to browsing the interrelated information.

By connecting to PDB, the legacy design information can be retrieved also.

Figure 12 shows the draft and a PRO/E model with design parameters for Base part of

Hubble Telescope created in our previous work.

Scenario 2: Reasoning on PSR

Supposing an engineer wants the design information of optical system of Hubble

Telescope (Figure8.III), he/she most probably doesn’t know the exact name of component in this assembly. However, it not necessary to worry about that, by just inputting “truss” in the Search facet (Figure 13), the lens truss(first result in Figure 13)

and top mirror truss(second result) as well as all related component: top mirror(third

result) and truss assembly(fourth result) are filtered out from all components of Hubble

Telescope assembly.

138

Figure 5 - 11: Present Product Data Semantics for Hubble Telescope Assembly -II: Table

Figure 5 - 12 : Design Information in PDB for Base part of Hubble Telescope

Further, this engineer may want to know more about the design context of every

component. For instance, how one component will affect the design parameters of other

components if some changes are made. The RuleSet1 in the previous section infers the

closel y related components based on the constraint information and it can be used here.

Figure 13 also displays the inference by RuleSet1 for top mirror (the third result in Figure

139

13). It shows that the top mirror is directly assembled to top mirror truss and c onnected to lens truss by another component. In other words, if this engineer plans to modify the design parameter of top mirror, e.g. the radius of it, he/she may need to consider adjusting the design parameters for top mirror truss and lens truss accordi ngly. For a large-scale assembly, which usually involves complex dependences between many components, this inference will be very helpful to figure out the relationship between components which is difficult to be found out in CAD systems.

Figure 5 - 13: Product Data Related to Truss of Hubble Telescope

140

Scenario 3: Link to Public Linked Data

From Scenario 1 and 2, the engineers are able to get design information from ontologies for product assembly domain in PSR and legacy design data stored in PDB. However, he/she may still need more information about Hubble Telescope, such as background, his tory, the information irrelevant to design or information about all telescopes. EPLD will offer this kind of information by linking to public linked data, such as DBpedia and

Free base. Figure 14 presents the querying results from DBpedia and Freebase usin g keyword “telescope”. We also visualize the results using Exhibit technology. DBpedia returns the telescope information in two domains: telescope instrument and telescope TV show. The URI of every result are supplied for further reading. Different from DB pedia,

Freebase returns the relevant score and the links of related image, article, etc. for every result. The corresponding RDF representation for a result stored in Freebase is also accessible with a GUID number.

Figure 5- 14 : Linking Results from DBpedia and Freebase

141

CONCLUSION

This paper proposed and implemented a product design semantic knowledge

management system (PD-SKMS) to realize a knowledge-contextual design environment

by integrating design information/knowledge with Semantic Web technologies for

engineers on the Web. A host hybrid-data repository, consisting of semantic repositories

and a conventional database, are set up as the back end of this system. Semantic

repositories capture the product data semantics for product design domain and the

conventional database stores the legacy design information. A Semantic data

management engine (SDME) has been implemented to exploit product data in the host

hybrid-data repository. By integrating the public linked data sources, the capacity of PD-

SKMS is extended with more semantic data on Web. The linking work in PD-SKMS

proves that semantic representation offers easier integration of diverse data. The Web- based user interface, the front end of PD-SKMS, allows engineers to assign querying/reasoning tasks as well as presents the retrievals in rich, dynamic visualizations.

It can be concluded this new approach for knowledge presentation improves the traditional presenting methods by bringing better user experiences and advancing process for knowledge comprehending and utilizing.

FUTURE WORK

There are still several issues needing to be further investigated :

• Extend host hybrid-data repository

For now, the product data stored in HDR comes from our previous work and it is still limited. More design information/knowledge in the product design domain for various products is needed to extend the current repository and testify PD-SKMS further.

142

• Improve capability of Semantic data management engine

As discussed in Section 5, some implementing work is still going on. One important work is allowing the engineer to authoring/updating the product semantic repository. A specific translator is needed here to help convert human user’s natural language into design knowledge. In addition, more SPARQL queries and rule sets will be defined to extend the querying/reasoning capability of SDME and exploit the growing product data semantics.

• Involve in the world of public linked data

In this paper, two public linked data sources are linked to PD-SKMS and they can supply additional information for engineers. However, very few professional product design information can be found from them. In the coming future, PD-SKMS will explore and link to more public linked data sources, e.g. productontology.org (Hepp,

2011). At the same time this system will publish the semantic data for product design domain and thus contribute to the Semantic Web community.

ACKNOWLEDGEMENTS

This work was partially supported by National Science Foundation (NSF) Grant

No. DMI 0523052; Hubble Telescope assembly is supplied by NSF Grant#11V3825560/

NSF REU Program: DMI and Thanks for Matthew Poppe’s contribution for the modeling work

143

REFERENCE

Cao, D.X, Ramani, K., & Liu, Y., et al. (2010). Developing Customer Preferences for

Concept Generation by Using Engineering Ontologies. Proceeding of 2010 ASME

IDETC/CIE Conference .

DBpedia (2007). Retrieved February 15, 2011, from http://dbpedia.org/

Fowler, D. & Crowder, R.M., et al (2010). Requirements for Semantic Web Applications

in Engineering. Proceeding of 2010 ASME IDETC/CIE Conference .

Franklin, M. J., Halevy, A. Y. & Maier, D. (2005). From Databases to Dataspaces: a New

Abstraction for Information Management. SIGMOD Record , 34(4):27–33.

Freebase (2007). Retrieved February 15, 2011, from

http://wiki.freebase.com/wiki/Main_Page

Fürber, C. & Hepp, M. (2010). Using SPARQL and SPIN for Data Quality Management

on the Semantic Web. Business Information Systems, 2010, Volume 47, Part 2, 35-46,

DOI: 10.1007/978-3-642-12814-1_4

Gero, J. S. & Maher, M. L. (1993). Introduction. In J. S. Gero and M. L. Maher (eds),

Modeling Creativity and Knowledge-Based Creative Design (pp. 1-6). Hillsdale, New

Jersey: Lawrence Erlbaum.

Gil, Y. (2011). Interactive Knowledge Capture in the New Millennium: How the

Semantic Web Changed Everything. Special Issue for the 25th Anniversary the

Knowledge Engineering Review.

144

Hepp, M. (2006). Products and Services Ontologies: A Methodology for Deriving OWL

Ontologies from Industrial Categorization Standards. International Journal on Semantic

Web and Information , 2(1): 72-99 (2006)

Hepp. M. (2008). GoodRelations: An Ontology for Describing Products and Services

Offers on the Web. Knowledge Engineer: Practice and Patterns , 2008, Volume

5268/2008, 329-346, DOI: 10.1007/978-3-540-87696-0_29

Hepp, M. (2011). The Product Types Ontology: Good identifiers for product types based on Wikipedia. Retrieved April 20, 2011, from http://www.productontology.org/

Hepp, M. & Radinger, A. (2010). eClassOWL- The Web Ontology for Products and

Services. Retrieved April 18, 2011, from http://www.heppnetz.de/projects/eclassowl/

Huynh, D.F., Karger, D.R. & Miller, R.C. (2007). Exhibit: Lightweight Structured Data

Publishing. International World Wide Web Conference Committee (IW3C2) .

Jain, P., Hitzler, P., Yeh, P. Z., Verma, K., & Sheth, A. P. (2009). Linked Data is Merely

More Data. Linked Data Meets Artificial Intelligence , 82–86. AAAI Press. Retrieved

April 18, 2011, from http://www.aaai.org/ocs/index.php/SSS/SSS10/paper/download/1130/1454

John D., Marko G. & Dunja M. (2008). Semantic Knowledge Management: Integrating

Ontology Management, Knowledge Discovery, and Human Language Technologies . New

York, NY: Springer.

Kim, O., Jayaram, U., Jayaram, S &Zhu, L. (2010). ITrain: Ontology-Based Integration of Information and Methods in Computer-Based Training (CBT) and Immersive Training

(IMT) for Assembly Simulation. Proceeding of 2010 ASME IDETC/CIE Conference.

145

Kim, O., Jayaram,U., Jayaram, S. & Zhu, L.J. (2009). An Ontology Mapping Application

Using A Shared Ontology Approach and A Bridge Ontolgy. Proceeding of 2009 ASME

IDETC/CIE Conference.

Koparanova, M. G. & Risch T. (2002). Completing CAD Data Queries for Visualization.

International Database Engineering and Applications Symposium (IDEAS'02) (pp. 130).

Li, Z., Raskin, V. & Ramani K. (2008). Developing engineering ontology for information

retrieval. Journal of Computing and Information Science in Engineering , Vol.8/011003-

1-13.

Morris, J. (2008). The Role of Ontology in Modern Expert Systems Development.

Received March 20, 2011, from http://www.slideshare.net/jcmorris/the-role-of-ontology- in-modern-expert-systems-dallas-2008-presentation.

Murshed, S.M.M., Dixon, A. & Shah, J.J. (2009). Neutral Definition and Recognition of

Assembly Features for Legacy System Reverse Engineering. Proceeding of 2009 ASME

IDETC/CIE Conference .

Nicklas, D., Ranganathan, A. & Riboni, D. (2010). A survey of context modelling and reasoning techniques. Pervasive and Mobile Computing , Volume 6, Issue 2, pp.161-180.

NIST (2002). STEP/EXPRESS and XML. Retrieved February 25, 2011, from http://xml.coverpages.org/stepExpressXML.html#step-part28. ontotext: OWLIM semantic Repository (2010). Retrieved January 20, 2011, from http://www.ontotext.com/owlim/. openRDF.org (2010). Retrieved January 20, 2011, from http://www.openrdf.org/.

146

Segaran, T., Evans, C. & Taylor, J. (2009). Programming the Semantic Web . Sebastopol,

CA: O’Reilly Media.

Sevilmis, N. & Stork, A., et al (2005). Knowledge Sharing by Information Retrieval in the Semantic Web. The Semantic Web: research and applications: Second European

Semantic Web Conference, ESWC 2005, pp. 471-485.

Sheth, A. (2010). Computing for Human Experience: Semantics-Empowered Sensors,

Services, and Social Computing on the Ubiquitous Web. IEEE Internet Computing -

Vision Issue (V. Cerf and M. Singh, Eds.) , vol. 14, no. 1, pp. 88-91, Jan./Feb. 2010, doi:10.1109/MIC.2010.4

Szykman, S., Sriram, R. D., Bochenek, C., Racz, J. W., & Senfaute, J. (2000). Design repositories: Engineering design’s new knowledge base. IEEE Intelligent Systems , 15(3),

48–55.

W3C: Semantic Web Frequently Asked Questions (2009). Retrieved February 20, 2011, from http://www.w3.org/RDF/FAQ.

W3C: SPARQL Query Language for RDF (2007). Retrieved February 25, 2011, from http://www.w3.org/TR/rdf-sparql-query/.

Watson, M. (2010). Practical Semantic web and Linked Data Application . Retrieved

February 20, 2011, from http://www.markwatson.com/.

Welty, C. (1999). Ontologies: Expert Systems all over again?. 1999 American

Association for Artificial Intelligence National Conference (AAAI-99)

Wikipedia: Linked Data (2011), Retrieved March 25, 2011, from http://en.wikipedia.org/wiki/Linked_Data.

147

Wikipedia: Semantic Web (2011), Retrieved March 25, 2011, from

http://en.wikipedia.org/wiki/Semantic_Web.

Wikipedia: Semantic web Stack (2010). Retrieved March 25, 2011, from

http://en.wikipedia.org/wiki/Semantic_Web_Stack.

Witherell, P., Krishnamurty, S., Grosse, I. & Wileden, J. (2009). Semantic Relatedness

Measures for Identifying Relationships in Product Development Processes. Proceeding of

2009 ASME IDETC/CIE Conference .

Zhan, P., Jayaram, U., Jayaram, S., Kim, O. and Zhu, L.J. (2010). Knowledge

Representation and Ontology Mapping Methods for Product Data in Engineering

Applications. Journal of Computing and Information Science in Engineering , June 2010,

Volume 10, Issue 2, 021004.

Zhan, P., Jayaram, U., Jayaram, S., Kim, O. & Zhu, L.J. (2008). Knowledge

Representation and Ontology Mapping Methods for Product Data in Engineering

Applications. Proceeding of 2008 ASME IDETC/CIE Conference.

Zhan, P., Jayaram, U. & Jayaram, S. (2007). A Semantic Approach for CAD/CAE

Integration. Proceedings of 2008 NSF Engineering Research and Innovation Conference .

Zhan, P. (2007). An Ontology-Based Approach for Semantic Level Inf ormation

Exchange and Integration in Applications for Product Lifecycle Management. Doctoral

Dissertation, Washington State University, Pullman, Washington.

Zhu, L.J., Jayaram, U., Jayaram, S. & Kim, O. (2010). Enabling Reasoning in Product

Assembly Ontologies – Moving past Modeling. Journal of Computing and Information

Science in Engineering. (Revision under Review).

148

Zhu, L.J., Jayaram, U., Jayaram, S. & Kim, O. (2010). Querying and Reasoning with

Product Engineering Ontologies-Moving Past Modeling. Proceeding of 2010 ASME

IDETC/CIE Conference.

Zhu, L.J., Jayaram,U., Jayaram, S. & Kim, O. (2009). Ontology-Driven Integration of

CAD/CAE Applications: Strategies and Comprisons. Proceeding of 2009 ASME

IDETC/CIE Conference

149

Chapter Six - Knowledge Representation and

Querying/Reasoning for PDM system

The chapter intends to extend the research work on ontology modeling and reasoning to PDM systems. It is important that the design knowledge can be integrated with engineering applications, e.g. CAD, PDM, etc. so that its value does not diminish or get obsolete. The following tasks are specifically addressed in this research area:

1) Investigate knowledge representation for PDM system and integrate product data

semantics in PDM ontology into ontology-driven integration framework

2) Investigate query and reasoning on PDM ontology to enhance PDM searching

capability

6.1 KNOWLEDGE REPRESENTATION AND INTEGRATION OF PDM

SYSTEM

PDM system supports design collaboration, design reuse and increased

cooperation among isolated departments, customers, and external partners. Traditionally,

PDM systems define and manage the product meta-data, leaving the bulky, detailed

geometric and other data to the CAD/CAM/CAE systems. Meta-data contains classifying,

descriptive, or attributive object information. For example, the traditional meta-data

cover such information as author, approver, supplier, version, change history, etc. On the

other hand, there are also “aggregate data” such as part number, BOM, product assembly

structure, etc.

150

Some researchers studied the product data integration about PDM systems, but their approaches are mostly based on STEP model. The STEP PDM Schema contains some of the most important standardized product meta-data models, in which a general product can be conceptually interpreted either as a part or as a document. The units of functionality for parts and documents covered by the STEP PDM Schemas include identification, versioning, product structures (including transformations), approvals and authorization, project, work order, work request, affectivities, classification and properties. 210 entities are defined to compose these units of functionality in the STEP

PDM Schema. Each of these 210 entities is defined in greater detail using the EXPRESS schema language.

However, the EXPRESS schema language lacks extensibility. It is hard for humans to read and, most limiting, is difficult for computer to interpret. Only a relatively small number of software that supports STEP can do the interpretation. To overcome this obstacle, we introduce knowledge representation into PDM with ontology modeling. The ontology language, OWL, facilitates greater machine interpretability along with a formal semantics. The final purpose is improving the traditional data transfer between CAD,

PDM, etc.

Here is a scenario making significance of the integration of CAD and PDM systems.

Problems: Because of mergers or acquisition activity, the employees use multiple CAD applications in the same company. This usually leads to a competition of these CAD applications and conversion gaps between the employees about the design.

151

Solution: If a common PDM system can be shared by these CAD applications, it makes easier for multiple CAD applications to co-exist within this company. Additionally, it is on a budget to buy one PDM system to manage data, instead of ones for each CAD system respectively. Figure 6 - 1 gives an ontology-driven framework to integrate CAD applications and PDM system.

Solution Details: The PDM ontology is instantiated by e.g. SolidWorks Enterprise PDM,

which manages product data for CAD App 4: Solid Works . If one employee changes

some design parameters of an assembly model in Solid Works , e.g. the number of bolts or

the size of the bolts: 1) PDM ontology captures these changes; 2) Changes information is

transferred to ASOs for CAD applications by ontology mapping;3) Data Semantics is

retrieved to CAD applications. Thus CAD App 1: PRO/E , CAD App 2: CATIA and CAD

App 3: AutoCAD can update these design parameters for the same assembly model in them accordingly.

Figure 6 - 1: Integration Framework of Multiple CAD Applications and PDM

System

152

Most of the commercial PDM provide open API to access information stored in

PDM system, so the product data, e.g. the author, approver, supplier, version, change

history, BOM, product assembly structure can be obtained by calling the API to

instantiate PDM ontology. Figure 6 - 2 illuminates a process of extracting product data

from SolidWorks Enterprose PDM and instantiating a PDM ontology. The PDMWorks

Workgroup Application Programming Interface (API) is an OLE programming interface

to PDMWorks Workgroup, which supply functions directly accessing to the PDMWorks

Workgroup environment. The meta-data information is usually stored within the PDM

system's database and can be instantiated into corresponding concepts in PDM ontology

directly. User data, e.g. CAD files or office files, is stored on file system level within so called electronic data vaults or as binary large object (BLOB) in the database without having direct access to internal contents. We can define a property, e.g. has_location to associate the file, which is instantiated as an instance of e.g. Document in the PDM ontology, with its physical location in the file system.

Figure 6 - 2: Extract and Instantiate Product Data Semantics for PDM Ontology

Product data semantics can be mapped between different ontologies. Once the

ontology mapping is completed, the product data sematics is transferred and will be

applied to multiple applications in the integrated framework. For the same example

mentioned in the forgoing scenario, if the change about the number of bolts is captured in

PDM ontology: the value of has_ quantity for the instance Bolt1 is modified from 4 to 6.

153

By using bridge ontology for mapping, Bolt1 in PDM ontology can be mapped to Bolt2

in CAD ontology, and has_ quantity in PDM ontology can be mapped to has_amount in

CAD ontology, so the value of has_amount for Bolt2 will be transferred and changed to 6

accordingly (Figure 6 - 3). In the same way, the change information can be transferred

procedural knowledge ontology. After the new number of bolts is retrieved from CAD

ontology and procedural knowledge ontology to CAD application and procedure plan

system, and the assembly model containing the bolts in the CAD application or assembly

sequence in which the bolts are involved will be refreshed automatically.

6 6

Figure 6 - 3: Ontology Mapping and Transfer of Product data semantics

Further, more application specific ontologies built on the 3-layered ontology structure, e.g. Training Ontology, PLM ontology, material resource planning(MRP) ontology, enterprise resource planning (ERP) ontolgy, etc., can be plugged into this framework (Figure 6 - 4). By this way, CAD, PDM systems are extended to connecting more existing business applications, such as MRP and ERP systems to allow a semantic interoperability across each other. Thus, product data storage and management, as well as processes and decision-making, will be supported on semantic level finally. And these ontologies are capable to evolve through product lifecycle.

154

Figure 6 - 4: Ontology Mapping and Integration between Multiple Ontologies

6.2 ONTOLOGY Q UERYING AND REASONING ON PDM ONTOLOGY

Another important capability PDM supplying is finding and reusing product designs or documenting specific product development processes. From a design engineer’s perspective, having the ability to find and view design-related documents, models, and files quickly and effortlessly may even be the most immediately recognizable benefit of implementing a PDM system. For example, subcontractors need to be able to view schedules and design changes that impact them. Program managers need to view the same data (and more) to track subcontractor critical path items for product development, manufacture, test, and delivery. The PDM systems store the product data in RDMS (Relational Database Management System) and its searching is based on metadata encompassing the file names, contained data, workflow state, or other

155

predefined search characteristics. The search capabilities of PDM still operate on keywords, instead of on semantics of data. Hence it faces new challenges:

a) Relationships and patterns in the PDM data need to be analyzed to support

opened-ended or complex user queries;

b) Every query function needs to be able to view the product data in the context in

which it will be used;

c) Data often needs to be collected, organized, processed, and displayed to satisfy

the requirements of different user groups so that the user has intelligible

information to act upon immediately

These requirements indicate that PDM systems may consider taking advantage of the engineering domain knowledge to achieve more effective information retrieval, because knowledge is not only contained in information itself, but also in the relationships among information items. By representing dispersed contents contained in

PDM and associating them for each other explicitly with ontology concepts and properties, the query on PDM system will be on a meaningful and contextual level. In addition, by codifying rules in PDM ontologies, new product data not explicitly expressed in PDM can be derived. The following may serve as query and reasoning examples we plan to implement initially:

 Query: What the product looks like?

Capability: allows different views of product to satisfy the various departmental

needs. For instance, the model designer views physical relationships between

parts in an assembly while manufacturing, financial, maintenance or document

relationships will be presented to corresponding specialist team members.

156

Results: model previews, BOM information and assembly structure if it is an

assembly

 Query: What the documents related to this product?

Results: documents tree, revisions and physical location of each document

resource

 Query: How about the product’s design?

Capability: an assembly cannot be released/approved if the associated sub-

assemblies and parts are not released/approved. By querying property, e.g.

is_released or is_approved for these sub-assemblies and parts, the property value

of is_released or is_approved for this assembly can be set.

Results: authors, approvers, release status, and change history including the

comments of authors and model views for any previous revisions

 Query: What is the product’s design context?

Capability: search all products related to this product, e.g. querying property,

assembleon on this product , is able to find other products which this product is

constrained on. If the related product has changed, the design of this product has

to be changed consequently. For example, when designing a panel with holes, the

size of hole should be adjusted if the mating screw’s size has been changed.

Results: change history and model views related to this product

 Query: Did we already design something like that before?

Capability: search geometric features of all products by querying property, e.g.

has_feature. For example, if user looks for a product design involving cylinder,

this query will find all instances of Part in the PDM ontology which has_feature

157

of an instance/instances of Cylinder. And then by querying these instances of Part

with is_componentof , all instances of Assembly which containing these parts can

be found.

Result: information of all parts and assemblies containing geometric features the

user defines

 Query: Which one should I choose from these analogous products?

Capability: make inference on these instances of Product by querying properties,

e.g. has_cost , is_stock , etc. These properties are set by users or applications as the

search criterions and assigned weighted values according to their importance

respectively. Thus the weight for every instance will be calculated based on its

values for these properties.

Result: a preferred products list in order of their weight values

In this way, the users don’t need to access the PDM system directly, and instead they can put queries and obtain the results through the local/web-based user interfaces.

Actually, many troubles are caused by users not knowing how to use PDM system properly.

158

Chapter Seven - Summary and Future Work

The chapter summarizes the research work in previous chapters and puts forward the future work which needs to be addressed and further investigated.

7.1 SUMMARY

This dissertation seeks to improve the product design process towards automatically and intelligently. The following research questions are investigated:

I. How to capture product data semantics from design tools, and thus enable

exchanging product data across the product lifecycle?

To solve the problems resulting from heterogeneous data types in

various engineering tools, our proposed solution is to build knowledge to

interpret product data as product data semantics and transfer between

different product data semantics.

II. Is it possible to retrieve product data and derive new product data semantics,

and how to implement it?

Ontology querying and reasoning are allowed to retrieve product data

and to derive new product data semantic not explicitly expressed in the

knowledge bases

III. How to reuse and preserve engineering knowledge for human engineers,

especially in today’s climate of computer-based social networking and

computational literacy?

159

Taking advantage of research in Chapter 3 and Chapter 4, we construct

an online knowledge-contextual design environment which allows to present,

query and author product design knowledge in engineering domains.

7.1.1 Semantic Integration of CAD/CAE Applications

This integration framework enables product data to be shared and exchanged across the product lifecycle. Ontology is a consistent and scalable way to represent knowledge in engineering design and analysis. We use a three layered structure to model engineering ontology: general ontology, domain ontology and application ontology. In an ontology, concepts are related to other concepts by different types of relations. In addition, axioms supplement the knowledge by defining the restrictions on the concepts and their relations.

We implemented the product data transfer from one kind of representation to another kind, hence different applications in the integration framework can collaborate and communicate seamlessly. Our research reveals that ontology provides superior support for the integration of heterogeneous data from multiple applications and allows an extension of existing product data semantics potentially by introducing reasoning mechanisms.

7.1.2 Ontology Querying and Reasoning

Ontology reasoning mechanisms hold great promise for improved knowledge discovery and understanding.

160

This research moves past ontology modeling work in Chapter 3 and extend ontologies with reasoning mechanisms, which makes two tasks possible in our semantic applications: retrieve existing product data semantics in knowledge base and infer new product data semantics from the knowledge base. The former task helps users understand and learn the knowledge base by extracting information from knowledge base to answer users’ queries. We can combine and adopt multiple views to recognize these retrieval results as needed. New reasoning units can be plugged in to retrieve more product data information according to user’s intents. The latter task is more significant for ontology- driven approaches. By defining rules, expression of OWL is extended and new knowledge can be derived. In our examples, the SWRL/SQWRL rule can simplify query task and they are employed to infer assembly sequence for assembly level and infer constraints between components for component level. In return, the inference results derived from existing knowledge enrich the knowledge base, as well.

7.1.3 Online Product Semantic Design Environment

This online product design environment is designed to enable the reuse and preservation of engineering knowledge in an interactive way for engineers distributed globally. This research takes advantage of previous research work on ontology and aims to capture the design knowledge, store it, keep it open to reuse, extensions and modifications, and integrate it during the product lifecycle.

The research work in Chapter 5 extends knowledge retrievals by linking to external public linked data sources, allows inquire/contribute design information from disparate

161

data sources and present rich, dynamic visualizations of product data semantics through the Web.

7.1.4 Key Contributions

Multiple applications have been developed for every research areas and there are several highlights which can be addressed for every research area. With example scenarios, we implemented and testified proposed strategies for knowledge modeling, semantic integration, ontology reasoning and product semantic design environment.

In summary, this dissertation is distinguished in the following contributions:

1) Semantic Integration of CAD/CAE Applications: We use product data

semantics as the interpretation of product data and capture the product data in

knowledge representations. This semantic approach results in a more adaptive

and extensible framework allowing the integration of multiple applications

across different domains based on knowledge representations of product data.

2) Ontology Querying and Reasoning: The semantic applications developed in

this research area provides a light weight access to CAD data and enables

some inference capabilities which are not supported by the current basic CAD

systems. Instead of replacing the CAD systems, they can be regarded a great

enhancement of CAD systems

3) Online Product Semantic Design Environment: We used Semantic Web

technologies to construct a knowledge-contextual design environment based

on the engineering ontologies. This online design environment provides a

more interactive way for engineers to exchange product data and design

162

information on the Web. An novel approach has been implemented to present

product data semantics in rich, dynamic visualizations through the Web

7.2 FUTURE WORK

There are still several issues needing to be further investigated:

1) Deployment adaptivity. As the engineering application in a CAD/CAE framework can be very different. For example, one application may require real-time collaboration, whereas another may require a strict, well-defined, procedure-based communication. Also in some cases the deployment is based on sharing just the product data (PDM model) whereas others require the complete integration of the engineering, manufacturing, and business processes (ERP model). Any resulting system based on current integration methods is very rigid in terms of deployment: deployment strategies often cannot be modified or replaced without subsequent rounds of negotiation and programming. There is an increasing demand for flexible deployment strategy that can support multiple deployment possibilities.

2) Allow flexible and customized reasoning task. It is very valuable to implement a custom-made semantic application to serve engineers on various knowledge levels considering they have different requirements for the product data. For now, the users are only allowed to choose the fixed terms offered by the user interface to make reasoning.

Query specifications and inference rules are expected to be generated dynamically according to the user’s intents or assignments. Thus, reasoning tasks will be executed in a more flexible manner.

163

3) Improve Online Product Semantic Design Environment. The Online Product

Semantic Design Environment implemented in Chapter 5 can be regarded as an initial stage of an on-line community (Figure 7-1) which will finally realize a knowledge- contextual design environment for reuse and preservation of engineering knowledge on the Web.

Figure 7 - 1: Overall framework for on-line community

This on-line community framework designed especially for engineers allows a coherent and sustainable method for the design knowledge management. It is aimed at capturing the knowledge from:

a) A community of experts and retired engineers, being of design experience

Creation, modification and interpretation of products require considerable

amount of engineering expertise. Knowledge loss because of retirement is a

164

serious problem facing organizations today. It is found that organizational

innovation is often compromised due to knowledge loss and that experience in

doing things the old way is often necessary and critical to do them in a new and

creative way.

b) A community of customers, by whom the products should be used

In many industries, customer feedbacks are a vital part of the product

development process. Providing controlled customer access to specific pieces of

design data can contribute to moving the development process forward. Although

these feedbacks are regarded as information instead of knowledge initially, we

believe useful ones can evolve into knowledge to some extent.

Thus, this on-line community enables a) practicing engineers to present queries and requests to a community of experts/retired engineers; b) customers to acquire the development process and comment on the present product design; c) experts/retired engineers to respond to the queries or requests and presents their opinions or answers.

Retired engineers will be encouraged to stay actively connected with their past profession, customers will be involved in the product development process and practicing engineers will obtain guidance and feedbacks on their designs from experts and customers. Consequently, everyone participates the product design process and all design activities will be driven by design knowledge. Product data sharing and exchanging exists not only between different product development phases but also between different enterprises. Moreover, the design knowledge will be integrated with engineering applications of CAD/CAE/PDM, so that its value does not diminish or get obsolete.

165

Appendix

Appendix A – Acronyms

CAD: Computer Aided Design

CAE: Computer Aided Engineering

PLM: Product Lifecycle Management

PDM: Product Data Management

GDO: General Domain Ontology

DSO: Domain Specific Ontology

ASO: Application Specific Ontology

PDD: Product Design Domain

ASD: Assembly Simulation Domain

FBM-DO: Feature Based Modeling Domain Ontology

ASM-DO: Assembly Modeling Domain Ontology

SIM-DO: Simulation Modeling Domain Ontology

PRO-AO: PRO/E Application Ontology

CAT-AO: CATIA Application Ontology

VADE-AO: VADE Application Ontology

KB: Knowledge Base

SWRL: Semantics Web Rule Language

SQWRL: Semantic Query-Enhanced Web Rule Language

RU: Reasoning Unit

SR: SWRL Rule

SQSP: SQWRL Specification

167

Appendix B – Rules for Ontology Querying and Reasoning

Reasoning Units Defined in Chapter 4:

Reasoning Capability Approach & Rules Unit(RU) RU1 List assembly component Query (Jena + Pellet) RU2 Construct composition hierarchy Query (Jena + Pellet) RU3A Retrieve Single component Query (Jena + Pellet) assembly Inference(SWRL+SQWRL): RU3B Two components RU3 constraint for SR1 , SQSP2 Infer geometry attribute of constraint Inference(SWRL+SQWRL): Assembly RU3C Level reference SRGoup1 RU4A Infer Assembly Sequence Inference(SWRL+SQWRL): RU4 Infer internal relationship of two RU4B SR2 ,SR3 , SQSP3 components RU5 Sort components’ volume Inference (SQWRL): SQSP1 Retrieve component’s transformation RU6 Inference (SQWRL) matrix RU7 Retrieve component’s geometry features Query(Jena + Pellet) Infer Component RU8A Insert Inference(SQWRL): constraints Level RU8 RU8B Mate/Align (surface) SQSP4 ,SQSP5 , between SQSP6 ,SQSP7 RU8C components: Align( axis)

SWRL Rules Defined in Chapter 4:

SWRL Rule for Interring Implied Assembling Relationships between Components

SWRL(SR1): has_assemblyreference(?x,?z) ∧∧∧ has_componentreference(?y,?z) ∧∧∧ Component(?x) ∧∧∧ Component(?y) ∧∧∧ Constraint(?z) → has_reference(?z,?x) ∧∧∧ has_reference(?z,?y)

Explanation: Conditions: Constraint z has assembly reference Component x and has component reference Component y Consequence: Constraint z has_reference Component x and Component y, i.e. z has x and y as its constraint references.

168

SWRL Rules for Inferring Geometry Attributes of Constraint Reference SWRL(SRGoup1): Mate(?x) ∧∧∧ Surface(?y) ∧∧∧ has_componentref_item(?x,?y) → Plane(?y) (1) Mate(?x) ∧∧∧ Surface(?y) ∧∧∧ has_assemblyref_item(?x,?y) → Plane(?y) (2) Insert(?x) ∧∧∧ Surface(?y) ∧∧∧ has_assemblyref_item(?x,?y) → Cylindrical_surface(?y) (3) Insert(?x) ∧∧∧ Surface(?y) ∧∧∧ has_componentref_item(?x,?y) → Cylindrical_surface(?y) (4) …

Explanation: Conditions: Mate x has assembly/component referenced model item y and y is an instance of Surface Consequence: y is an instance of Plane , i.e. planar surface. Note: rule (1) and (2) are defined for Mate (the similar explanation can be applied to rule (3) and (4) defined for Insert )

SWRL Rule for Inferring assembleon Relation between Components

SWRL(SR2): is_componentreference (?x,?z) ∧∧∧ is_assemblyreference(?y,?z) ∧∧∧ Component(?x) ∧∧∧ Component(?y) ∧∧∧ Constraint(?z) → assembleon(?x,?y) Explanation: Conditions: Component x is component reference of Constraint z, and Component y is assembly reference of Constraint z Consequence: Component x assembles on Component y

SWRL (SR3): assembleon(?x, ?y) → assembledwith(?x, ?y)

SQWRL Specifications Defined in Chapter 4:

SQWRL Specification for Retrieving All Parts Ordered by Their Volumes SQSP1(SQWRL): Part(?p) ∧∧∧ has_volume(?p,?v) ∧∧∧ has_name(?p,?n) → sqwrl:select(?n,?v) ∧∧∧ sqwrl:orderBy(?v)

Explanation: Conditions: Part p has volume v and has name n Consequence: Return pairs of name and volume for all instances of Part, ordered by the size of their volumes

169

SQWRL Specification for Retrieving Out Inference by SR1

SQWRL(SQSP2): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2) ∧∧∧ Constraint(?con) ∧∧∧ has_reference(?con,?c1) ∧∧∧ has_reference(?con,?c2) → sqwrl:select(?c1, ?con, ?c2) ∧∧∧ sqwrl:columnNames(\"Component #1\", \"Constraint\", \"Component #2\")

Explanation: c_name1 is Component c1’s name c_name2 is Component c2’s name Conditions: Constraint con has instance c1, named c_name1, and instance c2, named c_name2, as its constraint references Consequence: return c1, con, and c2

SQWRL Specification for Retrieving Out Inference by SR3

SQWRL(SQSP3): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2) ∧∧∧ Component(?c3) ∧∧∧assembledwith(?c1,?c3) ∧∧∧ assembledwith(?c3,?c2) → sqwrl:select(?c1, ?c3, ?c2) ∧∧∧ sqwrl:columnNames(\"Component #1\", \" Component(in-between)\", \"Component #2\")

SQWRL Specification for Inferring and Retrieving Out Constraint Insert (I)

SQWRL(SQSP4): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2 ∧∧∧ has_feature(?c1,?fea1) ∧∧∧ Protrusion(?fea1) ∧∧∧ has_modelitem(?fea1,?item1) ∧∧∧ Cylindrical_surface(?item1) ∧∧∧ has_feature(?c2,?fea2) ∧∧∧ Cut(?fea2) ∧∧∧ has_modelitem(?fea2,?item2) ∧∧∧ Cylindrical_surface(?item2) → sqwrl:select(?c1,?fea1,?item1,?c2,?fea2,?item2) ∧∧∧ sqwrl:orderBy(?fea1)

Explanation: c_name1 is Component c1’s name c_name2 is Component c2’s name Conditions: Component c1 has a Protrusion feature fea1 which contains a cylindrical surface item1 and Component c2 has a Cut feature fea2 which also contains a cylindrical surface item2 Consequence: c1 and c2 can be mated, return c1, fea1, item1, c2, fea2, item2, ordered by fea1

170

SQWRL Specification for Inferring and Retrieving Out Constraint Insert (II)

SQWRL(SQSP5): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2 ) ∧∧∧ has_feature(?c1,?fea1) ∧∧∧ Protrusion(?fea1) ∧∧∧ has_modelitem(?fea1,?item1) ∧∧∧ Cylindrical_surface(?item1) ∧∧∧ has_feature(?c2,?fea2) ∧∧∧ Hole(?fea2) ∧∧∧ has_modelitem(?fea2,?item2) ∧∧∧ Cylindrical_surface(?item2) → sqwrl:select(?c1,?fea1,?item1,?c2,?fea2,?item2) ∧∧∧ sqwrl:orderBy(?fea1)

Explanation: c_name1 is Component c1’s name c_name2 is Component c2’s name Conditions: Component c1 has a Protrusion feature fea1 which contains a cylindrical surface item1 and Component c2 has a Hole feature fea2 which also contains a cylindrical surface item2 Consequence: c1 and c2 can be mated, return c1, fea1, item1, c2, fea2, item2, ordered by fea1

SQWRL Specification for Inferring and Retrieving Out Constraint Mate/Align for Surface

SQWRL (SQSP6): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2) ∧∧∧ has_feature(?c1,?fea1) ∧∧∧ has_modelitem(?fea1,?item1) ∧∧∧ Plane(?item1) ∧∧∧ has_feature(?c2,?fea2) ∧∧∧ has_modelitem(?fea2,?item2) ∧∧∧ Plane(?item2) → sqwrl:select(?c1,?fea1,?item1,?c2,?fea2,?item2) ∧∧∧ sqwrl:orderBy(?fea1)

SQWRL Specification for Inferring and Retrieving Out Constraint Align for Axis

SQWRL (SQSP7): sameAs(?c1,c_name1) ∧∧∧ sameAs(?c2,c_name2 ) ∧∧∧ has_feature(?c1,?fea1) ∧∧∧ has_modelitem(?fea1,?item1) ∧∧∧ Axis(?item1) ∧∧∧ has_feature(?c2,?fea2) ∧∧∧ has_modelitem(?fea2,?item2) ∧∧∧ Axis(?item2) → sqwrl:select(?c1,?fea1,?item1,?c2,?fea2,?item2) ∧∧∧ sqwrl:orderBy(?fea1)

171

SPARQL Specifications and Rule Sets Defined in Chapter 5:

SPARQL SELECT Query Example: SPARQL0 For retrieving all assemblies containing sub components which have volume greater than 1000 cm 3

PREFIX PRO-AO: SELECT ?assembly ?subcomponent ?volume WHERE { ?assembly PRO-AD: has_component ?subcomponent . ?subcomponent PRO-AD: has_volume ?volume . FILTER (? volume > 1000) . } ORDER BY ?assembly ?volume

SPARQL SELECT Query on PSR: SPQRQL1 for retrieving a) components of the assembly; b) details of the component, including name, volume, materials, etc.; c) constraint information for every component;

SELECT * WHERE { { ?component rdf:type ?class . ?class rdfs:subClassOf PRO-AO:Component . ?component PRO-AO:has_name ?name . ?component PRO-AO:has_volume ?volume . OPTIONAL {?component PRO-AO:has_constraint ?constraint ?constraint PRO-AO:has_assemblyreference ?assembleto .} } UNION { ?component rdf:type ?class . ?class rdfs:subClassOf PRO-AO:Component . ?component PRO-AO:has_name ?name . ?component PRO-AO:has_component ?subcomponent . OPTIONAL {?component PRO-AO:has_constraint ?constraint . ?constraint PRO-AO:has_assemblyreference ?assembleto .} } } ORDER BY ?component SPARQL SELECT Query on PSR: SPQRQL2 for retrieving d) details of a constraint, including assembly reference, component reference, etc.

SELECT * WHERE { ?labelconstraint PRO-AO:has_assemblyreference ?assemblyreference . ?labelconstraint PRO-AO:has_assemblyref_item ?arefitem . ?labelconstraint PRO-AO:has_componentreference ?componentreference. ?labelconstraint PRO-AO:has_componentref_item ?crefitem . }

172

Ruleset1 for inferring e) internal relationship between components

Id: myrule1 x y y z ------x z

Id: myrule2 x y y z ------x z SPARQL SELECT Query on PSR: SPQRQL3 SELECT * WHERE { {?x PRO-AO:assembleon ?y .} UNION {?x PRO-AO:assembledwith ?z . }}

Ruleset2 for inferring f) geometry attributes of constraint reference

Id: myrule3 x y x y ------y

Id: myrule4 x y x y ------y

173

Appendix C – Core Code for Product Data Instantiation

//------// PROAOInstantiation.java : // 1.Extract assembly information from PRO/E using JLink API // 2.Instantiate PRO-AO with extracted assembly information using Jena API

//------// Author...: Lijuan Zhu @ VRCIM Lab // Date.....: 10/2008 //------import java.io.*; import java.util.ArrayList; import java.util.HashSet; import java.util.Iterator; import java.util.Set;

// Import packages from JLink API import com.ptc.cipjava.*; import com.ptc.pfc.pfcGlobal.*; import com.ptc.pfc.pfcSession.*; import com.ptc.pfc.pfcModel.*; import com.ptc.pfc.pfcGlobal.pfcGlobal; import com.ptc.pfc.pfcSession.Session; import com.ptc.pfc.pfcSolid.*; import com.ptc.pfc.pfcModelItem.*; import com.ptc.pfc.pfcFeature.*; import com.ptc.pfc.pfcGeometry.*; import com.ptc.pfc.pfcBase.*; import com.ptc.pfc.pfcComponentFeat.*; import com.ptc.pfc.pfcFamily.FamilyTableRow; import com.ptc.pfc.pfcSelect.*; import com.ptc.pfc.pfcAssembly.*;

// Import packages from Jena API import com.hp.hpl.jena.datatypes.xsd.XSDDatatype;

174

import com.hp.hpl.jena.ontology.*; import com.hp.hpl.jena.rdf.model.Literal; import com.hp.hpl.jena.rdf.model.ModelFactory; import com.hp.hpl.jena.rdf.model.Property; import com.hp.hpl.jena.query.Query; import com.clarkparsia.pellet.sparqldl.jena.SparqlDLExecutionFactory; import com.hp.hpl.jena.ontology.OntModel; import com.hp.hpl.jena.query.QueryExecution; import com.hp.hpl.jena.query.QueryFactory; import com.hp.hpl.jena.query.QuerySolution; import com.hp.hpl.jena.query.ResultSet; import com.hp.hpl.jena.query.ResultSetFormatter;

public class PROAOInstantiation {

public static String filepath = "F:\\Eclipse\\PRO-AO_Query\\data\\PRO-AO.owl"; // Original owl file path public static String outpath = "PRO-AO_Ins"; public static String namespace="http://www.wsu.edu/vrcim-onto/PRO-AO.owl#";

// variables for assembly information in PRO/E static OntModel O_model; static Individual inst_a, inst_con, inst_constrain,inst_featureitem,inst_for_ref; static String class_name,ins_name,class_going,level; static String[] property = new String[100]; static String[] comp_class_name = new String[100]; static String id = "", parent_n = "";

//variables for PRO-AO static Session session; static Model model;

static File outputFile; static FileOutputStream output; static PrintWriter results; static String sinst_n_temp;

175

//J-Link start method. //------public static void start () { try { // Get Pro/E session session = pfcGlobal.GetProESession();

// Get Current Model in Pro/E model = (Model) session.GetCurrentModel();

// Create an empty ontology model O_model = ModelFactory.createOntologyModel(); // load model from original owl file into the new empty ontology model loadModel();

//Exception if the model is empty or not an assembly if (model == null || model.GetType() != ModelType.MDL_ASSEMBLY) throw new RuntimeException ("Current model is not an assembly!");

// Populate information about Assembly (top level)in PRO-AO OntClass at_class = O_model.createClass(namespace+ "Assembly"); Individual inst_at= O_model.createIndividual(namespace+ model.GetInstanceName(),at_class);

outpath = outpath + "of"+ model.GetInstanceName()+ ".owl";

// Instantiate PRO-AO with assembly information from Pro/E model writeParts(model.GetInstanceName(), model.GetType(), 0);

// Save final PRO-AO containing instances writeModel();

} catch (jxthrowable x) {

176

printMsg("Exception caught: "+x); x.printStackTrace(); System.exit(-1); } catch (IOException iox) { printMsg("File I/O exception caught: "+iox); iox.printStackTrace(); System.exit(-2); } }

// Load PRO-AO containing no instances //------private static void loadModel() {

InputStreamReader in;

try { FileInputStream file = new FileInputStream(filePath); in = new InputStreamReader(file, "UTF-8"); // Read PRO-AO O_model.read(in, null); in.close(); } catch (FileNotFoundException e) { System.out.println("Cann't open the file! Exit now"); System.exit(0); } catch (IOException e) { e.printStackTrace(); System.exit(0); } }

177

// Extract assmebly information from PRO/E model, // build instances for corresponding concepts and // configure properties for these instances in PRO-AO //------private static void writeParts(String Name, ModelType Type, int Level) throws IOException, jxthrowable {

String subtype_name,item_name; Model assembly_model; ModelItemType item_type; OntClass con_class_sub,con_class; Individual inst_a_temp; String subname_temp="",class_name_temp_fea="",ins_num_s = "", p_name; int ins_num = 1, ins_f_num = 1; int i, j, k, assembly_modelsnum,ass_componentsnum; int p_num;

assembly_model = (Model) session.GetModel(Name, Type); if (assembly_model == null || assembly_model.GetType() != ModelType.MDL_assEMBLY) throw new RuntimeException ("Current model is not an assembly!");

// Get Current Model in Pro/E com.ptc.pfc.pfcassembly.assembly assembly = (com.ptc.pfc.pfcassembly.assembly)assembly_model;

Features ass_components = assembly.ListFeaturesByType (Boolean.FALSE,FeatureType.FEATTYPE_COMPONENT); ass_componentsnum = ass_components.getarraysize();

k = Level;

if(Level != 0) { class_name= "SubAssembly"; // If level is unequals to 0, the current model is a subassembly }

178

OntClass a_class = O_model.createClass(namespace+ class_name);

ins_name = Name;

if(Level != 0) { // Create instance for SubAssembly inst_a = O_model.createIndividual(namespace+ ins_name + id + "_"+ parent_n,a_class); sinst_n_temp = ins_name + id + "_"+ parent_n;

inst_a.addProperty(O_model.getDatatypeProperty(namespace+"has_id"), id, XSDDatatype.XSDint); } else inst_a = O_model.getIndividual(namespace + Name);

// Populate properties, e.g. has_name, has_componentnum inst_a.addProperty(O_model.getDatatypeProperty(namespace+"has_name"), Name);

inst_a.addProperty(O_model.getDatatypeProperty(namespace+"has_componentnum"),Int eger.toString(ass_componentsnum),XSDDatatype.XSDint);

inst_a_temp = inst_a; subname_temp = sinst_n_temp;

// Iterate every component in current model for (i =0; i < ass_componentsnum; i++) { ComponentFeat asmcomp = (ComponentFeat)ass_components.get(i);

// Get the model name id = Integer.toString(asmcomp.GetId());

parent_n = inst_a.getLocalName();

ModelDescriptor asmcomp_model= (ModelDescriptor)asmcomp.GetModelDescr();

if( asmcomp_model.GetType() == ModelType.MDL_ASSEMBLY )

179

{ // If the component is an assembly, do a recursion of writeParts() writeParts(asmcomp_model.GetInstanceName(),asmcomp_model.GetType(),++k); inst_a = inst_a_temp; }

class_name = modelTypeToString(asmcomp_model.GetType()); con_class = O_model.createClass(namespace+class_name); k = Level;

ins_name = asmcomp_model.GetInstanceName();

if(class_name.equals("Assembly")) { inst_con = O_model.getIndividual(namespace + sinst_n_temp); sinst_n_temp = subname_temp; } else { inst_con = O_model.createIndividual(namespace + ins_name + id+ "_"+ inst_a.getLocalName(),con_class);

inst_con.addProperty(O_model.getDatatypeProperty(namespace+"has_name"), asmcomp_model.GetInstanceName());

Solid solid_t = (Solid) session.GetModelFromDescr(asmcomp_model);

MassProperty properties; // Data Structure containing mass property data.

properties = solid_t.GetMassProperty(null); float p_volume = (float)properties.GetVolume();

// Populate property: has_volume for one component instance inst_con.addProperty(O_model.getDatatypeProperty(namespace+"has_volume"), Float.toString(p_volume),XSDDatatype.XSDfloat);

}

180

Matrix3D matrix = asmcomp.GetPosition().GetMatrix();

for(int m = 0; m < 4; m++) for(int n = 0; n < 4; n++) { float position = (float)matrix.get(m, n);

// Populate property: has_locationmatrix for one component instance

inst_con.addProperty(O_model.getDatatypeProperty(namespace+"has_ locationmatrix"), Float.toString(position) + "("+ m + "," + n + ")"); }

inst_con.addProperty(O_model.getObjectProperty(namespace+"is_component_of"), inst_a); inst_a.addProperty(O_model.getObjectProperty(namespace+"has_component"),inst_con);

// Populate property: has_part or has_subassembly for one component instance if(class_name.equals("Part")) inst_a.addProperty(O_model.getObjectProperty(namespace+"has_part"),inst_con); else if(class_name.equals("Assembly")){

inst_a.addProperty(O_model.getObjectProperty(namespace+"has_subassembly"),inst_co n);}

// Get constraints of component ComponentConstraints constrs = asmcomp.GetConstraints ();

// Continue for the next component if no contrants with current one if (constrs == null || constrs.getarraysize() == 0) {

inst_con.addProperty(O_model.getDatatypeProperty(namespace+"is_assemblyb ase"), "true",XSDDatatype.XSDboolean); continue; }

181

inst_con.addProperty(O_model.getDatatypeProperty(namespace+"has_constraintnum"), Integer.toString(constrs.getarraysize()),XSDDatatype.XSDint); for (j = 0; j

// Get constraint type ComponentConstraintType ctype = c.GetType ();

// Translate constraint type to terms accepted in PRO-AO String c_type_string = constraintTypeToString (ctype);

// Populate constraint concepts and properties OntClass constrain_class = O_model.getOntClass(namespace+ c_type_string); if (constrain_class == null) constrain_class = O_model.createClass(namespace+ c_type_string);

ins_num = 1; ins_name = c_type_string + Integer.toString(1);

// Create names for contraint instances of the same type if(O_model.getIndividual(namespace + ins_name)!= null){ while(O_model.getIndividual(namespace+ c_type_string+ Integer.toString(ins_num))!= null) ins_num++; ins_name = c_type_string + Integer.toString(ins_num); } inst_constrain = O_model.createIndividual(namespace+ ins_name,constrain_class); inst_con.addProperty(O_model.getObjectProperty(namespace+"has_constraint"), inst_constrain);

// Get assembly references and Populate corresponding concepts and properties in PRO-AO ...

// Get component references and Populate corresponding concepts and properties in PRO-AO

182

... } } }

// Save updated PRO-AO containing instances //------private static void writeModel() throws FileNotFoundException { outputFile = new File(outpath);

// Delete the old file if there is one if (outputFile.exists()) outputFile.delete();

// Set up output stream output = new FileOutputStream (outputFile);

results = new PrintWriter (output, true);

// Write updated PRO-AO O_model.write(results,"RDF/XML");

results.close(); }

// Convert the constraint type to terms accepted in PRO-AO //------private static String constraintTypeToString (ComponentConstraintType type) { switch (type.getValue()) { case ComponentConstraintType._ASM_CONSTRAINT_MATE: return ("Mate"); case ComponentConstraintType._ASM_CONSTRAINT_MATE_OFF: return ("Mate_Offset"); case ComponentConstraintType._ASM_CONSTRAINT_ALIGN:

183

return ("Align"); case ComponentConstraintType._ASM_CONSTRAINT_ALIGN_OFF: return ("Align_Offset"); case ComponentConstraintType._ASM_CONSTRAINT_INSERT: return ("Insert"); case ComponentConstraintType._ASM_CONSTRAINT_ORIENT: return ("Orient"); case ComponentConstraintType._ASM_CONSTRAINT_CSYS: ... } }

// Convert the model item type toterms accepted in PRO-AO //------private static String modelItemTypeToString (ModelItemType type) { switch (type.getValue()) { case ModelItemType._ITEM_FEATURE: return ("Feature"); case ModelItemType._ITEM_SURFACE: return ("Surface"); case ModelItemType._ITEM_EDGE: return ("Edge"); case ModelItemType._ITEM_COORD_SYS: return ("Datum_Coordinate_System"); ... } }

//Convert the model type to terms accepted in PRO-AO //------private static String modelTypeToString (ModelType type) { switch (type.getValue()) { case ModelType._MDL_ASSEMBLY:

184

return ("Assembly"); case ModelType._MDL_PART: return ("Part"); case ModelType._MDL_DRAWING: return ("Drawing"); case ModelType._MDL_2D_SECTION: return ("2D_Section"); case ModelType._MDL_LAYOUT: return ("Layout"); ... } }

private static String compTypeToString(ComponentType type) { switch (type.getValue()) { case ComponentType._COMPONENT_WORKPIECE: return ("COMPONENT_WORKPIECE"); case ComponentType._COMPONENT_REF_MODEL: return ("COMPONENT_REF_MODEL"); case ComponentType._COMPONENT_FIXTURE: return ("COMPONENT_FIXTURE"); case ComponentType._COMPONENT_MOLD_BASE: return ("COMPONENT_MOLD_BASE"); ... } }

// J-Link stop method. //------public static void stop () {

}

public static void printMsg(String Msg)

185

{ System.out.println(Msg); }

}

186

Appendix D – Toolkits Adopted for Delivered Applications 187