A Methodology for Product Family Ontology Development ... - CiteSeerX

18 downloads 2974 Views 1MB Size Report
Cover, Shutter Cover, Flash Cover, Material is not a formal concept. This is ..... tion Systems, N. Guarino, ed., June 6–8, Trento, Italy, IOS Press, Amsterdam,.
Jyotirmaya Nanda1 Graduate Research Assistant

Timothy W. Simpson2 Associate Professor of Mechanical and Industrial Engineering Member ASME e-mail: [email protected]

Soundar R. T. Kumara Distinguished Professor of Industrial and Manufacturing Engineering Member ASME The Pennsylvania State University, University Park, PA 16802

Steven B. Shooter Associate Professor of Mechanical Engineering Member ASME Bucknell University, Lewisburg, PA 17837

A Methodology for Product Family Ontology Development Using Formal Concept Analysis and Web Ontology Language The use of ontologies for information sharing is well documented in the literature, but the lack of a comprehensive and systematic methodology for constructing product ontologies has limited the process of developing ontologies for design artifacts. In this paper we introduce the Product Family Ontology Development Methodology (PFODM), a novel methodology to develop formal product ontologies using the Semantic Web paradigm. Within PFODM, Formal Concept Analysis (FCA) is used first to identify similarities among a finite set of design artifacts based on their properties and then to develop and refine a product family ontology using Web Ontology Language (OWL). A family of seven one-time-use cameras is used to demonstrate the steps of the PFODM to construct such an ontology. The benefit of PFODM lies in providing a systematic and consistent methodology for constructing ontologies to support product family design. The resulting ontologies provide a hierarchical conceptual clustering of related design artifacts, which is particularly advantageous for product family design where parts, processes, and most important, information is intentionally shared and reused to reduce complexity, lead-time, and development costs. Potential uses of the resulting ontologies and FCA representations within product family design are also discussed. 关DOI: 10.1115/1.2190237兴 Keywords: ontology, semantic web, formal concept analysis, product family

1

Introduction

Product representation schemes and design repositories have progressed remarkably in the past decade to facilitate platformbased product development and product family design to support mass customization 关1兴. In engineered products, one of the most critical business processes is managing product and process data over the total product lifecycle 关2兴. In addition to sharing and exchanging information, pressure to reduce product development time has resulted in an increased focus on methods for representing and storing engineering artifact knowledge in a way that facilitates its retrieval and subsequent reuse 关3兴. Successful product family planning places an even greater requirement on effective information management to exploit the potential of shared assets such as components, processes, and knowledge across products 关1兴. By sharing such assets, companies can efficiently develop differentiated products for a variety of market segments and increase the flexibility and responsiveness of their product realization process. During the early phases of product development, product design information remains rather incomplete and is often also inconsistent 关4兴. Collaborative design in such a heterogeneous and distributed design environment necessitates the use of ontologies as a common communication framework. Ontologies have been developed for many fields to establish common vocabularies and capture domain knowledge and have proven to be an advantageous paradigm over recent years 关5兴. Gennari et al. 关6兴 discuss the high payoff of saved effort due to reuse of pre-existing knowledge captured in an ontology. The use of ontologies in product family design promises similar, if not greater, benefits due to in1

Department of Industrial & Manufacturing Engineering. Corresponding author. Contributed by the Engineering Information 共EIX兲 Committee. Manuscript received December 21, 2004; final manuscript received December 23, 2005. Assoc. Editor: S. Szykman. 2

tended component sharing and reuse; however, the lack of a comprehensive and systematic methodology for constructing product ontologies has limited the process of developing, and subsequently using, design artifact ontologies. In this paper, we introduce the Product Family Ontology Development Methodology 共PFODM兲 to help address this limitation in Sec. 3. PFODM combines distinct, yet complementary, research in Formal Concept Analysis 共FCA兲, Semantic Web, and Web Ontology Language 共OWL兲, and related work in each of these areas is reviewed in the next section. In Sec. 4, a family of seven onetime-use cameras is used to demonstrate the use of PFODM to construct an ontology for a product family. Closing remarks and potential uses of the resulting ontologies and FCA representations within product family design are discussed in Sec. 5.

2

Background and Related Work

2.1 Methods for Ontology Development. An ontology consists of a set of concepts, axioms, and relationships that describes a domain of interest. These concepts and relationships between them are usually implemented as classes, relations, properties, attributes, and values 共of the properties/attributes兲 关7兴. An ontology can be defined as 关8兴: “An ontology is a formal, explicit specification of a shared conceptualization.” The terms “formal” and “explicit” enable the automatic machine-based interpretation of the conceptualization; “shared” enables the sharing, combination, and integrated use of ontological information 关9兴. Many well-known ontologies can be found in the literature, e.g., WordNet 关10兴, RosettaNet,3 Cyc 关11兴 knowledge base, and National Cancer Institute caCORE 关12兴; see Ref. 关13兴 for an extensive review. While ontologies have found many applications in the field of 3

http://www.rosettanet.org

Journal of Computing and Information Science in Engineering Copyright © 2006 by ASME

JUNE 2006, Vol. 6 / 103

knowledge representation and knowledge processing, the use of pre-existing knowledge captured in ontologies has had limited success in engineering design. Among the limitations, the ontology development process was primarily monolithic in nature until only recently. Development of a single global integrated ontology for the whole organization is impractical and implausible, which gives rise to the use of multiple domain-specific ontologies 关14兴 to provide semantic interpretation of data. Defining a common vocabulary, formalizing an ontology development process, and implementing it becomes an exceedingly important step in a distributed knowledge-sharing environment, and few methodologies exist for creating formal ontologies. Uschold and King 关15兴 present a “skeletal model” for the design and evaluation of ontologies. Gruninger and Fox 关16兴 developed a methodology for design and evaluation of ontologies while developing the TOVE 共Toronto Virtual Enterprise兲 project ontology. Fernandez et al. 关17兴 present a structured method and technique for building ontologies from scratch, called METHONTOLOGY. Staab et al. 关18兴 present a methodology that makes a distinction between the knowledge process and the knowledge meta-process. In product design, even though some work exists in formalizing design knowledge 关19兴, we have not found any systematic methodologies for proceeding from design vocabulary to ontological implementation. The lack of a comprehensive and integrated methodology for building product ontologies has limited the process of developing design artifact ontologies, which are critical to support the development of shared and distributed design repositories 关3,20兴. The methodology introduced in Sec. 3 focuses on creating OWL ontologies for representing artifacts that are shared within a product family. 2.2 Formal Concept Analysis. Formal concept analysis 共FCA兲 is used for analyzing data and forming semantic structures that are formal abstractions of concepts of human thought 关21兴. FCA borrows its mathematical foundation from order theory, the theory of complete lattices 关22兴 in particular. Cimiano et al. 关23兴 recently proposed an application of FCA in natural language processing 共NLP兲 for acquisition of domain concept hierarchies, and in this paper, we use FCA to identify similarities among a finite set of design artifacts based on their properties and develop and refine an ontology using OWL. 2.2.1 Some Basic Definitions of Formal Concept Analysis. Following the presentation of basic notions of concept analysis, key definitions of FCA follow 关21兴. Some terminology has been slightly modified to facilitate the understanding of OWL constructs in conjunction with FCA. DEFINITION 1. A formal context is a triple K ª 共C , P , R兲, where C is a finite set of objects (henceforth referred to as classes), P is a finite set of attributes (henceforth referred to as properties), and R is a binary relation between C and P. DEFINITION 2. A relation R is represented as a sub-set of the cross product between the finite sets of classes and properties, i.e., R 債 C ⫻ P. If a class c1 has property p1, where c1 苸 C and p1 苸 P, then the relationship is represented as 共c1 , p1兲 苸 R. The mappings captured by relation R give rise to a Galois connection 关24兴. DEFINITION 3. Common properties for a set of classes C1 債 C C1⬘ ª ␴共C1兲共=兵P1 苸 P兩 " C1 苸 C:共C1, P1兲 苸 R其兲 and correspondingly common classes for a set of properties P1 債 P

Table 1 Simple cross table

ordered set represented by Bគ 共K兲 = 共B共K兲 , 艋 兲 with 共C1 , P1兲 艋 共C2 , P2兲 : Û C1 債 C2共ÛP1 傶 P2兲. The formal concept 共C1 , P1兲 in this case is called a formal sub-concept of formal concept 共C2 , P2兲. There are several algorithms for computing a concept lattice from a given formal context 关25兴. DEFINITION 6. A cross table is a table that captures the relationship between classes C and properties P. The classes are represented as rows of the cross table and the properties as columns. The binary relation R between a class and a property is captured by putting a checkmark in the cross table as shown in Table 1. DEFINITION 7. A many valued formal context 共C , P , W , R兲 consists of sets C, P, and W and a ternary relation R between C, P, and W (see Table 2兲, i.e., R 債 C ⫻ P ⫻ W for which it holds that 共c , p , w兲 苸 R and 共c , p , v兲 苸 R always imply w = v. The notation 共c , p , w兲 苸 R is read as “the property p has value w” for the class c. The many valued properties are regarded as partial maps from C in W. Conceptual scaling 关21兴 is the methodology that is used on many-valued contexts to derive the concept lattice. Using this method, the many valued contexts are first transformed into single-valued contexts and then interpreted as the concepts of the many-valued context. DEFINITION 8. A context K ª 共C , P , R兲 is called clarified if for any classes C1, C2 苸 C, C1⬘ = C2⬘ Þ C1 = C2. Correspondingly for all P1, P2 苸 P, P⬘1 = P⬘2 Þ P1 = P2. THEOREM 1. 关21兴. The concept lattice Bគ 共K兲 is a complete lattice 关22兴 for which the infimum (greatest common formal sub-class) and supremum (smallest common formal sub-class) are given by Eqs. 共1兲 and 共2兲, respectively

共 共 共 兲兲兲 where I is an Index set V 共C , P 兲 = ␶ ␴ 艛 C , 艚 P where I is an Index set 共 共 共 兲兲 兲

⌳ 共Ci, Pi兲 = 艚 Ci, ␴ ␶ 艛 Pi

i苸I

i苸I

i苸I

i

i

i苸I

i苸I

i

i苸I

i

共1兲 共2兲

The theorem states that in order to compute the infimum of two classes, their extents must be intersected and their intents must be joined; the latter set of properties must then be “blown up” in order to fit to the class set of the infimum. Analogously, the supremum of two classes is computed by intersecting the properties and joining classes. In FCA, a concept lattice is graphically represented using a line diagram known as a Hasse Diagram 关21兴. A Hasse Diagram is a graphical rendering of a partially ordered set displayed via the cover relation of the partially ordered set with an implied upward orientation of generalization. Hence more precise information about the classes can be obtained by traversing down the lattice’s structure. The nodes in the Hasse Diagram of a context are labeled dually with the classes 共below兲 and properties 共above兲 and the vertices represent the relationship between the classes 共see Sec. Table 2 Multi-context cross table

P1⬘ ª ␶共P1兲共=兵C1 苸 C兩 " P1 苸 P:共C1, P1兲 苸 R其兲 DEFINITION 4. A formal concept of K is represented by the elements of B共K兲 ª 兵共C1 , P1兲 兩 C1 債 C , P1 債 P , C⬘1 = P1 , P⬘1 = C1其; hence, a formal concept is a combination of a set of classes (called its extent) and a set of properties (called its intent) such that all classes have all properties and all properties belong to all classes. DEFINITION 5. A Galois or concept lattice of K is a partially 104 / Vol. 6, JUNE 2006

Transactions of the ASME

Fig. 1 Product family ontology development methodology „PFODM…

4.3 for an example兲. A reduced labeling scheme is often used wherein each class and property appear only once in the diagram. 2.2.2 Software Tools for FCA. There are a number of software tools developed in the last two decades to support context creation and visualization in FCA, e.g., General Lattice Analysis and Design 共GLAD兲 关26兴, Contexts and Implications 共ConImp兲 关27兴, Concept Explorer 共ConExp兲,4 and Tools of Concept Analysis 共TOSCANA兲 关28兴, including the Java version, ToscanaJ.5 In this paper, we use ToscanaJ to analyze components that are part of a one-time-use camera product family. Apart from being platform independent, ToscanaJ supports richer graph visualization in terms of Hasse Diagrams and numerical analysis of the concepts that are part of a formal context. A detailed discussion on these and various other tools can be found in Ref. 关29兴. 2.3 Semantic Web and Web Ontology Language. The Semantic Web group at World Wide Web Consortium 共W3C兲6 is developing enabling standards and technologies to help machines understand more information on the Web and support richer discovery, data integration, navigation, and automation of tasks. The Web Ontology Language 共OWL兲7 is currently the most expressive language for specifying, publishing, and sharing ontologies, and is the only standard web ontology language. OWL facilitates greater machine interpretability of web content than that supported by XML,8 Resource Description Framework 共RDF兲,9 and RDF Schema 共RDFS兲,10 by providing additional vocabulary along with a formal semantics. OWL is well suited for design knowledge representation by supporting reasoning outside the transaction context, i.e., avoiding a protocol specification to handle standard data format. Any knowledge base expressed in OWL implicitly includes the axioms and definitions from OWL’s ontology and facilitates machine interpretability. OWL is backed by Description Logic 共DL兲 关30兴, which makes it easier for computers to interpret the semantics without human intervention. Software tools, irrespective of the subject domain, can provide support for the ontologies. Instead of trying to capture all the knowledge about a domain in a single ontology, OWL promotes distributed ontology development and enables them to be linked. As such, OWL ontologies can store the structure of several products in a product family in multiple distributed ontologies and facilitate design information sharing over the Internet through design repositories. This is also useful for concurrent product family development where the semantics of multiple products need to be shared across multiple stages of product development. Packages such as Protégé 关31兴 provide graphical user interfaces for ontology editing, and Jena 关32兴 has application programming interfaces for generic OWL manipula4

http://sourceforge.net/projects/conexp http://toscanaj.sourceforge.net/ http://www.w3.org 7 http://www.w3.org/TR/owl-features/ 8 http://www.w3.org/XML/ 9 http://www.w3.org/TR/rdf-primer/ 10 http://www.w3.org/TR/rdf-schema/ 5 6

tion and a rule-based inference engine. OWL comes in three sub-languages—OWL Lite, OWL DL, and OWL Full—to support different levels of expressiveness. We employ OWL DL in our work because it provides computational completeness 共i.e., all entailments are guaranteed to be computed兲 and decidability 共i.e., all computations will finish in finite time兲 while providing more expressiveness than OWL Lite. OWL Lite supports only classification hierarchy and simple constraints, and OWL Full is meant for users who want maximum expressiveness and the syntactic freedom of RDF with no computational guarantees. A typical OWL ontology contains a sequence of annotations, axioms, and facts that provide information about classes, properties, and individuals in the ontology. Axioms are used to associate class and property identifiers with partial or complete specifications of their characteristics and to provide other information about classes and properties. Finally, an OWL DL document, like all OWL documents, conforms to XML syntaxes. An OWL DL class represents the generic concept of the vocabulary. Classes, representing design artifacts in our case, are arranged into conceptual hierarchies. The “rdfs:subClassOf” construct specifies the class subsumption relationship between design artifacts, in the spirit of object oriented programming. Objects represent the implementation of conceptual design artifact classes and are represented by the construct “individual.” Properties, represented by “rdfs:property,” are used to state relationships between individuals or from individuals to data values. Properties may have certain characteristics, e.g., transitive, functional, symmetric, inverse, cardinality. Properties can also form hierarchies. The “rdfs:subPropertyOf” construct captures such a relationship. All the properties usually belong to a domain 共e.g., a product family兲 and is captured using the construct “rdfs:domain.” A domain of a property limits the individuals 共instances of classes兲 where the property can be used. If the property has a range, then it limits the individuals that the property may have as its value. OWL DL properties can have restrictions that dictate the usage of a property in an instance of a class. OWL DL requires a pairwise separation between classes, data types, data type properties, object properties, annotation properties, ontology properties, individuals, data values and the built-in vocabulary so that, for example, a class cannot be an individual at the same time. A detailed summary of OWL DL constructors, data ranges, axioms, and facts can be found in Ref. 关33兴.

3 A Methodology for Product Family Ontology Development A structured methodology for product family ontology construction will facilitate shared, consistent, and traceable ontology development in a diverse product development environment. Figure 1 illustrates our novel ontology development process called Product Family Ontology Development Methodology 共PFODM兲 for constructing product family ontologies using FCA and OWL. In the proposed PFODM, special importance is given to the tabular and graphical representation of product design artifacts and

Journal of Computing and Information Science in Engineering

JUNE 2006, Vol. 6 / 105

Table 3 Pairwise comparison of classes Type

Example

Entailment

Quadrant

1 2 3

c1 Ú c2 c1 Ù c2 共c1 Ù c2兲 Ú c2

Parallel class/dissimilar Same class/synonym c1 subsumes c2

A and C B A and B

their properties using FCA to readily tie to an existing design repository. The steps are described in the sections that follow. 3.1 Step 1: Component Lexicon Acquisition and Pruning. In this first step, a set of terms describing the components in a product family along with the required properties is acquired from the Bills of Materials 共BOMs兲 or by dissecting the products to the component and/or subassembly level of interest if BOMs are not readily available. If a product already has a bijective mapping of design terms and components 共e.g., a BOM兲, then this step is not necessary. In this paper we have followed the subtract-and-operate 共SOP兲 procedure 关34兴 for generating a listing of components and the functionalities of the one-time-use cameras through product dissection. After disassembly of the products in a family, a lexicon set is developed of all the components that includes synonyms of their description and properties. This provides the necessary terms based on which the product family ontology will be constructed in a dictionary form. In the component lexicon pruning stage, a bijective mapping between components and their descriptions is formed from the lexicon set. For bijective mapping, synonyms of a component’s descriptions are grouped together, and a single description is chosen out of the group to represent these components. 3.2 Step 2: Formal Contexts Composition. The classes and the properties developed in Step 1 are next represented in a cross table. The relationship between the properties and classes are captured from which the formal contexts are composed. The cross table can capture both binary and multi-valued properties. In capturing the properties for the design artifacts, multi-valued properties are most often used from which many valued formal contexts are formed. The many valued formal contexts are used to develop the product family concept lattice using FCA. To reduce the number of classes required to describe the product domain, a clarified context is created from the initial many valued formal context. Developing a clarified context requires grouping similar classes together 共aggregation兲, which can result in information loss about the domain. To keep the ontology developed from the clarified context sufficiently representative of the domain, the designer may decide to keep some clarified classes separate even if they can be grouped. An intermediate formal context is formed from the clarified context that contains all the classes the designer decides to keep for the development of the product family ontology. Examples of each are given in Sec. 4. 3.3 Step 3: Concept Hierarchy Formulation using FCA. From the intermediate formal context formed in Step 2, a concept lattice for the design artifacts is created using FCA. The partial order set of the concept lattice is used to develop the subsumption hierarchy of the product family ontology. The concept lattice developed from the intermediate formal context groups clarified classes at the same level in the subsumption hierarchy. When representing the subsumption hierarchy of the product family concept lattice in an OWL ontology, the designer may decide to impose an order hierarchy on the clarified classes. Though imposition of order hierarchy on clarified classes seems redundant, it helps reduce information loss due to aggregation and improves the reliability and adaptability of the ontologies for changes. Order hierarchy is imposed on the clarified classes that belong to a single group using pairwise comparison of the classes using positive and negative instance examples 共see Table 3兲. 106 / Vol. 6, JUNE 2006

Fig. 2 Graphical representation of AND-NOT quadrant

To determine the relationship between two classes, c1 and c2, examples and counter-examples of the two clarified classes are used from the product family domain. If separately we can provide examples of c1 and c2 classes in a product family but cannot provide an example of both together, then they satisfy the clause c1 Ú c2 and are parallel classes. The pairwise comparison of the clarified classes to form parallel or hierarchical representation of the classes can also be represented graphically using the ANDNOT quadrant as shown in Fig. 2. The designers can also use the AND-NOT quadrant, which represents Table 3 in a graphical format for deciding the relationship between clarified classes. In the case of the AND-NOT quadrant, the designer tries to come up with examples for as many quadrants of the table as possible, and the coverage of the quadrant decides the relationship between the classes. In case of parallel classes c1 and c2, the designer can only come up with examples for quadrants A and C, i.e., an example of a component that belongs to class c1 NOT c2 共quadrant C兲, and a component that belongs to class c2 and NOT c1 共quadrant A兲. An example of developing subsumption hierarchy in OWL ontology from the concept lattice in conjunction with pairwise comparison of the clarified classes is presented in Sec. 4.4.

3.4 Step 4: Product Family Ontology Formation and Enrichment using OWL. During the development of the class subclass hierarchies using FCA, constructs like owl:class, owl:subclass, owl:datatypeproperty, owl:objectproperty are primarily used. The initial product family ontology hierarchy formed using FCA is enriched by capturing various constraints, characteristics, and relationships between different classes and properties. Constructs for ontology headers like rdfs:comment, owl:priorVersion, rdfs:label, and owl:AnnotationProperty can be used to capture information about the generated OWL file. Components are declared as individuals that belong to various classes. Components even if belonging to a same class can be different physically, and this is captured in the ontology using owl:AllDifferent and owl: distinctMembers. The owl:equivalentClass construct helps in defining classes as equivalent and is used to describe components that are similar to each other at the concept level. Properties that are part of the ontology are improved using rdfs:range and owl:minCardinality constructs. The exact data types of owl:datatypeproperty are indicated with XML Schema data types. Constructs like owl:oneOf, rdf:List, and rdf:rest are used to define enumerated data types. After declaring the concepts and properties, PFODM provides a process of generating OWL ontologies that does not require further user interpretation. The PFODM will be primarily used by design knowledge engineers while developing and managing product family design repositories. To demonstrate the use of PFODM to construct an ontology, products and components from a family of one-time-use cameras are represented in OWL DL format next. Transactions of the ASME

Table 4 Summary of one-time-use camera family †35‡

Table 5 Initial multi context cross table of Kodak:cover class No.

Initial classes

Material

Weight

Color

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Cover Shutter cover Flash cover MAX outdoor shutter cover MAX flash shutter cover MAX HQ shutter cover Plus digital shutter cover Black & white shutter cover MAX water & sport shutter cover Advantix switchable shutter cover MAX flash flash cover MAX HQ flash cover Plus digital flash cover Black & white flash cover Advantix switchable flash cover

⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻

⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻

⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻ ⫻

4 Application of the Product Family Ontology Development Methodology 4.1 Overview of the One-time-use Camera Family. The one-time-use camera family consists of seven cameras manufactured by Kodak that are readily available in the market with specific functions: flash, digital processing, waterproof, black and white, and APS 共Advanced Photo System兲 with switchable format. These cameras encompass many of the characteristics of a typical product family, and the major distinguishing characteristics of each camera are listed in Table 4. To demonstrate the steps of PFODM, we discuss the kodak: cover class that is a part of this family in the sections that follow. The formal context and the concept lattice of the one-time-use camera family ontology are formalized using ToscanaJ as mentioned in Sec. 2.2.2. The OWL DL product family ontology was created and enriched using Protégé-2000, one of the most popular ontology editing tools 关36兴, with the OWL11 and ezOWL12 plugins that allow users to construct ontologies, customize data entry forms, and enter instances of the ontology. 4.2 Step 1: Component Lexicon Acquisition and Pruning. To develop the lexicon set for the one-time-use camera family, the cameras are first disassembled to the component level. A compo11

http://protege.stanford.edu/plugins/owl/ http://iweb.etri.re.kr/ezowl/index.html

12

Shutter cover shape

Flash cover shape

1 1 2 2 2 2 3 1 1 1 2 3

nent is a part of the camera that cannot be further decomposed into design artifacts. After the products are disassembled, all the terms associated with the components are collected in a dictionary form, including any synonyms for the components. Based on this dictionary of terms or lexicon set the product family ontology is formalized. For example, the lexicon set for describing the shutter cover for the MAX Outdoor camera can be L1ª 兵MAX Outdoor Shutter Cover, Shutter Cover of MAX Outdoor, MAX Shutter Cover其. In the next step, the lexicon set is reduced such that a one-to-one relationship is formed between the component and the term describing it; hence, after lexicon pruning, the shutter cover for the MAX Outdoor camera is L1ª 兵MAX Outdoor Shutter Cover其. All of the other synonyms for the component can still be saved for reference, but they will not be used as a part of the formal ontology. Properties of the components that are of interest for the one-time-use camera domain, e.g., P1ª 兵Weight, Material, Color其, are also collected. 4.3 Step 2: Formal Context Composition of the Cover Class. The second step is to put the lexicon set in a cross table with the rows describing the classes and the columns capturing the properties. For the kodak:cover class, Table 5 shows the initial cross table for all the shutter and flash covers of the one-time-use camera family with all the shutter covers as rows and their properties as columns. After disassembling the covers, we found that there are three types of shutter covers and three types of flash covers based on

Journal of Computing and Information Science in Engineering

JUNE 2006, Vol. 6 / 107

Table 6 Clarified cross table of kodak:cover class

No. 1 2 3 4 5

6 7 8 9

Clarified classes

Initial classes

Cover Shutter cover Flash cover MAX shutter cover

Cover Shutter cover Flash cover MAX outdoor shutter cover MAX flash shutter cover MAX HQ shutter cover MAX HQ shutter cover Plus digital shutter cover Black & white shutter cover MAX water & sport shutter cover APS shutter cover Advantix switchable shutter cover MAX flash cover MAX flash flash cover MAX HQ flash cover Plus digital flash cover Black & white flash cover Black & white flash cover Advantix switchable flash cover Advantix switchable flash cover

their shape. In Table 5 the relation R between these cover classes and their multi-context properties is captured. For example, the tuple 共MAX Outdoor Shutter Cover, Shutter Cover Shape 1兲 is in R, but 共Shutter Cover, Flash Cover Shape 1兲 is not. As defined in FCA, a formal concept is a maximal collection of classes sharing common properties. In Table 5, 共兵Cover, Shutter Cover, Flash Cover其, 兵Material, Weight, Color其兲 is a formal concept whereas 共兵Cover, Shutter Cover, Flash Cover其, 兵Material其兲 is not a formal concept. This is because ␴ 共兵Cover, Shutter Cover, Flash Cover其兲 ª 共兵Material, Weight, Color其兲. Also based on the basic theorem of

Fig. 3 Entering the kodak:cover context into ToscanaJ

Material weight Shutter cover Flash cover color shape shape ⫻

1



1



2

⫻ ⫻

3

⫻ ⫻

1 2 3

FCA, 共兵MAX Outdoor Shutter Cover, MAX HQ Shutter Cover其, 兵Material, Weight, Color, Shutter Cover Shape 1其兲 is a formal subconcept of 共兵Cover, Shutter Cover, Flash Cover, MAX Outdoor Shutter Cover, MAX Flash Shutter Cover其, 兵Material, Weight, Color其兲. The initial context presented in Table 5 can be manually manipulated to make a clarified context by merging classes with the same properties and properties with the same classes. The clarified context does not alter the original concept lattice. The clarified context for the covers in Table 5 is presented in Table 6. For example, the classes 共兵MAX Outdoor Shutter Cover, MAX Flash Shutter Cover其兲 have the same properties; hence, they are grouped as a single clarified class 共兵MAX Shutter Cover其兲. In this example, the clarified classes 共兵Cover, Shutter Cover, Flash Cover其兲 are kept separate despite having common properties to reduce the information loss during ontology formulation while making the ontology adaptable for future changes. Similarly the properties 共兵Material, Weight, Color其兲 are kept separate. In the intermediate formal context of the kodak:cover class the number of classes is reduced from the initial 15 to 9 as shown in Table 6. The development of the OWL ontology for the kodak:cover class resulting from Table

Fig. 4 Concept lattice of the kodak:cover generated by ToscanaJ

108 / Vol. 6, JUNE 2006

Transactions of the ASME

兵Cover其 and 兵Shutter Cover其, the designer tries to provide examples for the AND-NOT quadrants. We can provide examples of components that satisfy 兵Cover其 AND 兵Shutter Cover其, and 兵Cover其 NOT 兵Shutter Cover其, but we cannot provide an example of a component that is 兵Shutter Cover其 NOT 兵Cover其. This is illustrated in Fig. 5. The examples entail 兵Cover其 as a super-class of 兵Shutter Cover其 in the OWL ontology as they satisfy 共c1 Ù c2兲 Ú c2. The concept lattice is used to formalize the one-timeuse camera product family ontology given next.

Fig. 5 AND-NOT quadrant for ˆCover‰ and ˆShutter Cover‰

6 in conjunction with supervised pairwise comparison is described next. 4.4 Step 3: Concept Hierarchy Formulation using FCA. The intermediate formal context is entered in ToscanaJ for creating the concept lattice of the kodak:cover context. The data entry for ToscanaJ is shown in Fig. 3. The conversion of the information in Table 6 to the representation shown in Fig. 3 is currently done manually; however, we are currently investigate ways of automating this process. The Hasse diagram in Fig. 4 represents the partially ordered structure or the concept lattice of the kodak:cover context induced by the relationship between the classes and properties presented in Table 6. ToscanaJ automatically generates the Hasse diagram once given the information shown in Fig. 3. This example of the kodak: cover context demonstrates one possibility to interpret the formal concept lattice shown in Fig. 4, namely, it provides a hierarchical conceptual clustering of design artifacts for the cover, which may not have been identified through manual inspection of a set of BOMs. The AND-NOT quadrant presented in Fig. 2 is next used to find the relationship between clarified classes 共兵Cover, Shutter Cover, Flash Cover其兲. For example, to find the relationship between

4.5 Step 4: Kodak Camera Family Ontology Formation and Enrichment. The order hierarchy of the concept lattice formed using FCA in Fig. 4 is used to form the class sub-class hierarchy of the OWL ontology shown in Fig. 6. The partial ordering of the concept lattice facilitates the formation of subclasses of the kodak:cover class. A component in a sub-class inherits all the properties of the parent class. For instance, the class “FlashគCover” is defined with properties such as “hasគWeight,” and all the child classes 共i.e., sub-classes兲 inherit this property. The formation of the OWL ontology from the concept lattice is currently done manually but could be automated; we are currently investigating algorithms to accomplish this. In this example, the “APSគFlashគCover” class and the “MAXគFlashគCover,” sub-classes of “FlashគCover,” also have “hasគWeight” as a property. All the sub-classes have an “is a” relationship with their parent classes. An individual of type “MAXគFlashគCover” is a “FlashគCover,” which belongs to the “Cover” domain. All of the properties of class “Cover” show up in “MAXគFlashគCover.” When designing new components in the one-time-use camera product family, the designer simply extends 共i.e., creates sub-class of兲 one or more of the existing components. Thus the class diagram not only captures the relationship among components but also helps trace the evolution of the components in a product family. The properties of the camera ontology classes are either DatatypeProperty or ObjectProperty. Data type properties are given preference while describing basic attributes of a component,

Fig. 6 OWL representation of kodak:cover class

Journal of Computing and Information Science in Engineering

JUNE 2006, Vol. 6 / 109

Fig. 7 Property reference of component class

and they are grouped together in generic classes that form object properties. For example, all the classes that belong to the base class “Component” have Weight, Color, and Material that are object properties as shown in Fig. 7. Thus, the “Washer” class that is a sub-class of class “Component” has the “hasគWeight” property. To capture the weight of a washer, the “hasគWeight” ObjectProperty of the washer class’s “Weightគinគgrams” DatatypeProperty, which is a float, needs to be completed. The full listing of the base class “Component” for the one-time-use camera family is given in Fig. 8. A screen capture of the implementation of the ontology for the one-time-use cameras using Protégé is shown in Fig. 9. On the left, the classes are displayed; the information regarding the current class is either viewed on the right or in a new window. The example shows the class “Film” with its list of properties. Some of these properties are inherited from the parent class “Component” while others are specific to the class. For example, the properties “hasគWeight,” “hasគMaterial,” “hasគColor,” etc., are part of the parent class “Component,” whereas “hasគExposure,” “hasគSensitivity,” and “IsគBlackគandគWhite” are properties associated with class “Film” and its sub-classes. As discussed previously, OWL provides a layered set of constructs for different levels of machine interpretability of design information. This representation of design terms and their interrelationships can be enriched by the use of these terms in the ontology hierarchy. Some of the OWL constructs that are used to enrich the kodak:cover class are shown in Fig. 10. The enrichment process is done manually by the design knowledge engineers after the ontological class hierarchy is formed and the properties are associated with the classes. The concept lattice of the one-time-use cameras that are part of the product family is shown in Fig. 11. The order hierarchy of classes 共兵Camera其, 兵Single use Film Camera其, 兵Film Camera 35 mm其, 兵MAX Camera其, 兵MAX Camera Waterproof其兲 is highlighted in the figure using dotted lines. The order hierarchy of the concepts helps in developing the OWL ontology for the product family. The subsumption hierarchy of the classes of Fig. 11 is captured using OWL and is shown in Fig. 12. To illustrate the transformation of the concept lattice into OWL ontology the camera classes that are highlighted in Fig. 11 are also highlighted in Fig. 12. Figure 13 shows the source code of the OWL ontology. The first few lines of the ontology contain the annotation part and specify all the URI references. All the classes, sub-classes, and properties are in the first part of the ontology; the individuals 共objects of the classes兲 follow. Since the OWL file conforms to the XML standard, it can be read by any XML parser 共it is displayed using Internet Explorer’s XML parser in Fig. 13兲. The complete ontology is available at: http://edog.mne.psu.edu/owl/kodak.owl. 110 / Vol. 6, JUNE 2006

Using the one-time-use camera product family ontology product designers can explore various types of cameras as well as the components that are part of the camera product family. The onetime-use camera product family ontology can also be queried using semantic queries based on graph pattern matching that can span multiple products across the entire ontology. For example, the RDQL query “SELECT ?classAnyCamera, ?instanceFlash WHERE 共?classAnyCamera, 具KodakFamily:HasគFlash典, ?instanceFlash兲 USING KodakFamily FOR 具http:// edog.mne.psu.edu/ontology/kodak#典” will query the ontology and list all the cameras and their corresponding flash components 共i.e., classes with the ‘‘HasគFlash’’ property兲 within the family. For this example, it returns 兵共PlusគDigital, FlashគMax兲, 共MAXគFlashគCamera, FlashគMax兲, 共MAXគHQ, FlashគMax兲, 共AdvantixគSwitchable, FlashគAPS兲, 共BlackគandគWhite, FlashគBlackគandគWhite兲其, an array of cameras and their flash components. We are currently investigating ways to use similar queries to help identify common, variant, and unique components within the family.

5

Closing Remarks

In this paper three distinct yet interrelated ideas—product family design, FCA, and OWL—have been synthesized to create a systematic and consistent methodology for ontology development to support product family design, namely, the Product Family Ontology Development Methodology 共PFODM兲. Representing the product family as an ontology, which essentially is a directed

Fig. 8 Component class and sub-classes of the one-time-use camera ontology

Transactions of the ASME

Fig. 9 Protégé IDE showing the camera ontology

Fig. 10 Ontology enrichment of kodak:cover class

Fig. 11 Concept lattice of the kodak:camera generated by ToscanaJ

Journal of Computing and Information Science in Engineering

JUNE 2006, Vol. 6 / 111

for product family design management that includes customer needs, functions, and components. We are also developing an efficient algorithm for automatic translation of concept lattice of varying sizes into OWL. The FCA representations are also finding use in product family redesign. Specifically, we are developing component-based and product-based approaches to traverse a product family’s concept lattice to improve component commonality and help redesign a family 关37兴. All of this research is geared toward realizing a generalized information infrastructure based on shared design repositories to support product platform planning and product family management. Fig. 12 Camera class hierarchy representation using ezOWL

Acknowledgment cyclic graph structure, helps relate every notion of product family design with each other. The method of constructing ontologies using PFODM imposes traceability on the development of formal ontologies and minimizes user intervention for a consistent construction of product family ontologies, which can later be linked to other ontologies within an organization over the Internet. The resulting ontologies provide a hierarchical conceptual clustering of related design artifacts, which is particularly advantageous for product family design where parts, processes, and mostly importantly, information is intentionally shared and reused to reduce complexity, lead-time, and development costs. A family of seven one-time-use cameras is used to demonstrate the steps of PFODM to construct an ontology. PFODM helped us categorize the different cameras in the product family and provided a hierarchical conceptual clustering that might not have been identified through manual inspection of a set of BOMs. The next step in this particular line of research is to define ontologies of different product families within the same domain—we are currently using Fuji’s one-time-use cameras—and in other domains. This will help not only in generating a common domainlevel ontology for one-time-use cameras but also in analyzing commonality across product families. We are currently exploring multiple uses of the resulting ontologies and FCA representations to support product family design. For instance, once the ontology is fully constructed, the user can easily add a new product 共i.e., an instance of a class兲 to the ontology. To do this, the user simply adds a new instance in the corresponding class, e.g., “Camera-KodakគSingleគuseគCamerasMAXគCamera,” which will automatically have all of the properties from this class; new parts can then be added as needed to provide specific functionality for the new camera. PFODM is useful for creating ontologies to support a unified information model

Fig. 13 Sample of the one-time-use camera OWL ontology

112 / Vol. 6, JUNE 2006

This work was funded by the National Science Foundation under Grant Nos. IIS-0325402 and IIS-0325321. Any opinions, findings, and conclusions or recommendations presented in this paper are those of the authors and do not necessarily reflect the views of the National Science Foundation.

Nomenclature O 共C, P兲 P R c p ␴ 共C兲 ␶ 共P兲 ⌳ V I L W

⫽ ⫽ ⫽ ⫽ ⫽ ⫽ ⫽ ⫽ ⫽ ⫽ ⫽ ⫽ ⫽

K ª 共C , P , R兲 K ª 共C , P , WR兲 B共K兲 B共K兲 ª 艋

⫽ ⫽ ⫽ ⫽ ⫽ ⫽

ontology formal concept formal property incidence relation OWL class OWL property common attributes of C common classes of P infimum supremum individual Lexicon value of a property in multi-valued formal context formal context many valued formal context set of all concepts of context K concept lattice is defined as partial ordering

References 关1兴 Simpson, T. W., 2004, “Product Platform Design and Customization: Status and Promise,” Artif. Intell. Eng. Des. Anal. Manuf., 18共1兲, pp. 3–20. 关2兴 Bourke, R., 1999, “Product Information Management: Product Lifecycle Management in Complex Industries,” http://industrydirections.com/midrange/ rb0499.htm, March, 24, 2004, MidRange ERP. 关3兴 Szykman, S., Racz, J., Bochenek, C., and Sriram, R. D., 2000, “Web-Based System for Design Artifact Modeling,” Des. Stud., 21共2兲, pp. 145–165. 关4兴 Claesson, A., Johannesson, H., and Gedell, S., 2001, “Platform Product Development: Product Model a System Structure Composed of Configurable Components,” 13th International Conference on Design Theory and Methodology, September 9–12, Pittsburgh, PA, American Society of Mechanical Engineers, 4, pp. 317–326. 关5兴 Zhang, S., Shen, W., and Ghenniw, H., 2004, “A Review of Internet-Based Product Information Sharing and Visualization,” Comput Ind., 54共1兲, pp. 1–15. 关6兴 Gennari, J. H., Tu, S. W., Rothenfluh, T. E., and Musen, M. A., 1994, “Mapping Domains to Methods in Support of Reuse,” Int. J. Hum.-Comput. Stud., 41共3兲, pp. 399–424. 关7兴 Daconta, M. C., Obrst, L. J., and Smith, K. T., 2003, The Semantic Web: A Guide to the Future of XML, Web Services, and Knowledge Management, Wiley, Indianapolis, IN. 关8兴 Gruber, T. R., 1993, “A Translation Approach to Portable Ontology Specifications,” Knowl. Acquis., 5共2兲, pp. 199–220. 关9兴 Hyvönen, E., 2001, “The Semantic Web—The New Internet of Meanings,” Semantic Web Kick-Off in Finland—Vision, Technologies, Research, and Applications, October, 2, Helsinki Finland, Helsinki Institute for Information Technology Publications, Helsinki, pp. 3–26. 关10兴 Fellbaum, C., 1998, WordNet: An Electronic Lexical Database (Language, Speech, and Communication), MIT, Cambridge, MA. 关11兴 Reed, S. L., and Lenat, D. B., 2002, “Mapping Ontologies into Cyc,” American Association for Artificial Intelligence Conference Workshop on Ontologies

Transactions of the ASME

for the Semantic Web, July 28-August, 1, Edmonton, Canada, AAAI. 关12兴 Covitz, P. A., Hartel, F., Schaefer, C., Coronado, S. D., Fragoso, G., Sahni, H., Gustafson, S., and Buetow, K. H., 2003, “caCORE: A common infrastructure for cancer informatics,” Bioinformatics, 19共10兲, pp. 2404–2412. 关13兴 Nanda, J., Thevenot, H., Simpson, T. W., Kumara, S. R. T., and Shooter, S. B., 2004, “Exploring Semantic Web Technologies for Product Family Modeling,” International Design Engineering Technical Conferences and Computers & Information in Engineering Conference, Salt Lake City, UT, ASME, DETC2004/CIE-57683. 关14兴 Mena, E., Kashyap, V., Illarramendi, A., and Sheth, A., 1998, “Domain Specific Ontologies for Semantic Information Brokering on the Global Information Infrastructure,” International Conference on Formal Ontology in Information Systems, N. Guarino, ed., June 6–8, Trento, Italy, IOS Press, Amsterdam, The Netherlands. 关15兴 Uschold, M., and King, M., 1995, “Towards a Methodology for Building Ontologies,” International Joint Conference on Artificial Intelligence, August 20– 25, Montreal, Quebec, Canada, AIAI-TR-183. 关16兴 Gruninger, M., and Fox, M. S., 1995, “Methodology for the Design and Evaluation of Ontologies,” International Joint Conference on Artificial Intelligence, August 20–25, Montreal, Quebec, Canada. 关17兴 Fernández-López, M., Gomez-Perez, A., and Sierra, J. P., 1999, “Building a Chemical Ontology Using Methontology and the Ontology Design Environment,” IEEE Intell. Syst., 14共1兲, pp. 37–46. 关18兴 Staab, S., Studer, R., Schnurr, H.-P., and Sure, Y., 2001, “Knowledge Processes and Ontologies,” IEEE Intell. Syst., 16共1兲, pp. 26–34. 关19兴 Kumara, S. R. T., Ham, I., Al-Hamando, M., and Goodnow, K., 1989, “Causal Reasoning and Data Abstraction in Component Design,” CIRP Ann., 38共1兲, pp. 145–149. 关20兴 Bohm, M. R., Stone, R. B., and Szykman, S., 2005, “Enhancing Virtual Product Representations for Advanced Design Repository Systems,” ASME J. Comput. Inf. Sci. Eng., 5共2兲, pp. 360–372. 关21兴 Ganter, B., and Wille, R., 1999, Formal Concept Analysis: Mathematical Foundations, 1st ed., Springer, Heidelberg, Germany. 关22兴 Gratzer, G. A., 1998, General Lattice Theory, 2nd ed., Birkhäuser, Boston, MA. 关23兴 Cimiano, P., Hotho, A., Stumme, G., and Tane, J., 2004, “Conceptual Knowledge Processing with Formal Concept Analysis and Ontologies,” Concept Lattices: Second International Conference on Formal Concept Analysis (ICFCA), P. Eklund, ed., February 23–26, Sydney, Australia, Springer, Berlin, pp. 189– 207. 关24兴 Erné, M., Koslowski, J., Melton, A., and Strecker, G. E., 1991, “A Primer on Galois Connections,” Proceedings of the Summer Conference on General Topology and Applications in Honor of Mary Ellen Rudin and Her Work, S. Andima, R. Kopperman, P. Misra, M. E. Rudin, and A. R. Todd, eds., June 26–29, Madison, WI.

关25兴 Snelting, G., 1996, “Reengineering of Configurations Based on Mathematical Concept Analysis,” ACM Trans. Softw. Eng. Methodol., 5共2兲, pp. 146–189. 关26兴 Duquenne, V., Chabert, C., Cherfouh, A., Delabar, J.-M., Doyen, A.-L., and Pickering, D., 2001, “Structuration of Phenotypes/Genotypes Through Galois Lattices and Implications,” International Workshop on Concept Lattice-Based Theory, Methods and Tools for Knowledge Discovery in Databases, E. M. Nguifo, M. Liquière, and V. Duquenne, eds., July, 30, Stanford University, Stanford, CA. 关27兴 Burmeister, P., 2003, “Formal Concept Analysis with ConImp: Introduction to the Basic Features,” Department of Mathematics 共Arbeitsgruppe Allgemeine Algebra und Diskrete Mathematik兲, Darmstadt University of Technology, Darmstadt, Germany. 关28兴 Groh, B., Strahringer, S., and Wille, R., 1998, “TOSCANA-Systems Based on Thesauri,” Conceptual Structures: Theory, Tools and Applications: 6th International Conference on Conceptual Structures (ICCS’98), M.-L.Mugnier and M. Chein, eds., Montpellier, France, Springer, Heidelberg, Vol. 1453, pp. 127– 138. 关29兴 Tilley, T., 2004, “Tool Support for FCA,” Concept Lattices: Second International Conference on Formal Concept Analysis (ICFCA), P. Eklund, ed., February 23–26, Sydney, Australia, Springer, Berlin, pp. 104–111. 关30兴 Baader, F., Calvanese, D., McGuinness, D., Nardi, D., and Patel-Schneider, P., 2003, The Description Logic Handbook: Theory, Implementation and Applications, Cambridge University Press, Cambridge, UK. 关31兴 Noy, N. F., Sintek, M., Decker, S., Crubézy, M., Fergerson, R. W., and Musen, M. A., 2001, “Creating Semantic Web Contents with Protege-2000,” IEEE Intell. Syst., March–April 2001, 48共2兲, pp. 60–71. 关32兴 McBride, B., 2002, “Jena: A Semantic Web Toolkit,” IEEE Internet Comput. Mag., Nov.-Dec. 2002, 6共6兲, pp. 55–59. 关33兴 Patel-Schneider, P. F., and Horrocks, I., 2003, “OWL Web Ontology Language Semantics and Abstract Syntax,” http://www.w3.org/TR/owl-semantics/ syntax.html, March, 20, 2004, The World Wide Web Consortium. 关34兴 Otto, K., and Wood, K., 2000, Product Design: Techniques in Reverse Engineering, Systematic Design, and New Product Development, Prentice Hall, NY. 关35兴 Thevenot, H. J., 2003, “A Comparison of Commonality Indices for Product Family Design,” Industrial Engineering, The Pennsylvania State University, University Park, PA. 关36兴 Denny, M., 2004, “Ontology Tools Survey, Revisited,” http://www.xml.com/ pub/a/2004/07/14/onto.html, November, 22, 2004, O’Reilly XML.com. 关37兴 Nanda, J., Thevenot, H., and Simpson, T. W., 2005, “Product Family Representation and Redesign: Increasing Commonality using Formal Concept Analysis,” ASME International Design Engineering Technical Conferences & Computers and Information in Engineering Conference, September 24–28, Long Beach, CA, DETC2005-84818.

Journal of Computing and Information Science in Engineering

JUNE 2006, Vol. 6 / 113