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
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 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: 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 Id: myrule2 x 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 Id: myrule4 x 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: 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 Id: myrule2 x Ruleset2 for inferring f) geometry attributes of constraint reference Id: myrule3 x Id: myrule4 x 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