Available online at www.sciencedirect.com

www.elsevier.com/locate/eswa

Expert Systems with Applications 36 (2009) 2300–2309

Expert Systemswith Applications

Design of product ontology architecture for collaborative enterprises

Jeongsoo Lee a, Heekwon Chae a, Cheol-Han Kim b, Kwangsoo Kim a,*

a Department of Industrial and Management Engineering, Pohang University of Science and Technology, San 31, Hyoja-dong, Nam-gu, Pohang,

Kyungbuk 790-784, Republic of Koreab Division of Information Communications and Internet Engineering, Daejeon University, 96-3, Yongun-dong, Dong-gu, Daejeon 300-716, Republic of Korea

Abstract

As enterprises are subject to cope with frequently changing business environment, enterprises should integrate value chains such assupply chain and design chain. Sharing product information must precede for the integration. However, because most of the participantshave different business experience and business domains, interoperability of product information among enterprises should be guaran-teed for collaboration. To achieve interoperability, we suggest product ontology architecture through the investigation of generic ontol-ogy architecture. We first suggest 4-layered ontology architecture for an integrated value chain. Extending this ontology architecture, wedevelop product ontology architecture which facilitates building product ontologies that are referred to all related participants inboundand outbound of the enterprise for collaboration. Using a product ontology, each enterprise can have semantic interoperability acrosseach other for collaborative works. Because product ontologies have the feature of evolving through product lifecycle, the proposedproduct ontology architecture reflects this evolving feature to guarantee semantic interoperability.� 2007 Elsevier Ltd. All rights reserved.

Keywords: Ontology; Ontology architecture; Product ontology architecture; Collaborative enterprise; Semantic interoperability

1. Introduction

As enterprises are subject to cope with frequently chang-ing business environment, enterprises should integratevalue chains such as supply chains, design chains, and mar-keting chains in order to reduce time-to-market (Choi,Kim, & Kim, 2005; Jagdev & Thoben, 2001; Perrin & God-art, 2004). Sharing product information must precede forintegration between enterprises that participate into a valuechain. However, most of the participants have differentbusiness experience and business domains, interoperabilityof information among enterprises should be guaranteed inorder that enterprises collaborate with other participantsfor integration of value chain. There are two kinds of inter-operability of information: syntactic and semantic. Syntac-

0957-4174/$ - see front matter � 2007 Elsevier Ltd. All rights reserved.

doi:10.1016/j.eswa.2007.12.042

* Corresponding author. Tel.: +82 54 279 8231; fax: +82 54 279 5998.E-mail addresses: jsrhyme@postech.ac.kr (J. Lee), hkchae@poste-

ch.ac.kr (H. Chae), chkim@dju.ac.kr (C.-H. Kim), kskim@postech.ac.kr(K. Kim).

tic interoperability can be achieved by definingelectronically exchanged scheme such as EDI and ebXMLthat can be processed through one-to-one mapping, whilesemantic interoperability which will enable machine-under-standable data to be shared across the value chain can beachieved by ontological engineering process (SICoP, 2006).

Although there are many issues of interoperability forintegration of value chain, we focused on securing semanticinteroperability of product information for the productdevelopment phase in this paper, as product informationof an enterprise is the most basic information which isreferred to not only departments in the enterprise but alsothe related participants out of the enterprise for collabora-tion. For the semantic interoperability of product informa-tion, a product ontology which is commonly used by therelated enterprises which participate in the value chain,especially the design chain, should be built. The functionof the design chain during the new product developmentis very important because more than two-thirds of all prod-uct lifecycle cost is determined during the conceptual

J. Lee et al. / Expert Systems with Applications 36 (2009) 2300–2309 2301

design process (O’Marah, 2002). Hence, the enterprises inthe design chain must be capable of collaborating seam-lessly with each other (Choi et al., 2005). To support this,an ontology of product information is required to be builtsince semantics should be shared during collaborationamong all enterprises.

Building ontologies can be facilitated on a basis of acommon architecture for ontology, that is, the ontologyarchitecture. This is because the ontology architecturecan provide systematic procedure for building ontologiesby categorizing characteristics of ontologies. And also theontology architecture can act as an ontology integrationtool by classifying each characteristic of ontologies andproviding semantic interoperability among ontologies.For this reason, we suggest product ontology architecturebased on the proposed generic ontology architecture.Because product ontologies have the feature of evolvingthrough product lifecycle, the proposed product ontologyarchitecture should reflect this evolving feature to guaran-tee semantic interoperability. A product ontology of anenterprise based on the product ontology architecture isreferred to all related participants inbound and outboundof the enterprise for collaboration and provide semanticinteroperability for collaborative works.

In Section 2, we describe ontology and the generic ontol-ogy architecture which supports semantic interoperability.Section 3 describes product ontology architecture basedon proposed generic ontology architecture. Finally we con-clude this work in Section 4.

2. Ontology architecture

2.1. Overview of ontology

Although there is some disagreement on the definition ofan ontology (Noy & Hafner, 1997; Pisanelli, Gangemi, &Steve, 2002), generally an ontology is defined as an explicitspecification of a conceptualization (Gruber, 1993). A con-ceptualization is the extraction of vocabularies from adomain and is an abstract, simplified view of the world thatwe wish to represent for some purpose. Through this con-ceptualization, concepts and their relations are extractedfrom the real world. Because ontologies consist of theshared vocabularies used to describe the concepts and therelations (Guarino, 1998), ontologies can be used as toolsfor specifying the semantics of terminology systems in awell defined and unambiguous manner (Gruber, 1993;Guarino, 1998). Jasper and Uschold identified three majoruses of ontologies (Jasper & Uschold, 1999): (i) to assist incommunication between human beings, (ii) to achieveinteroperability (communication) among software systems,and (iii) to improve the design and the quality of softwaresystems. In this paper we focus on (i) and (ii) from theviewpoint of communication (semantic interoperability).

To guarantee semantic interoperability in a domain, acommon ontology for the domain should exist. Otherwise,a new ontology should be built. If semantic interoperability

across different domains is needed, a new temporal ontol-ogy for a virtual domain which includes all related domainsshould be built (Kalfoglou & Schorlemmer, 2002). Such anew ontology is built through the following procedure:identify purpose, ontology capture, ontology coding, inte-grating existing ontology, evaluation, and documentation(Uschold & King, 1995). There is an agreement in theontology community that the integration of existing ontol-ogies is more beneficial way to eliminate time, cost, andeffort for building a new ontology (Noy & Hafner, 1997).Guaranteeing semantic interoperability among ontologyfor integration is a key factor for building ontologies effi-ciently and guaranteeing semantic interoperability acrossdomains (Lee, Chae, Kim, & Kim, 2006).

2.2. Ontology architecture

Fig. 1 shows the generic ontology architecture proposedin this paper. The ontology architecture has 4 axes: syntac-tic meta-layers, theoretic meta-layers, domain layers, andconstructive layers.

2.2.1. Syntactic meta-layers based on MDAMain axis of the ontology architecture is based on model

driven architecture (MDA) that adapts four-layer meta-modeling architecture that has a number of standardsdefined at each of its layers (Lee et al., 2006). The topmostlayer (M3) called meta–meta-model contains meta-objectfacility (MOF) that is a self-defined language intended fordefining meta-models (Object Management Group, 2002).Examples of the meta-models of MDA are UML and com-mon warehouse meta-model (CWM). The meta-model layeris usually denoted as M2. At this layer we can define a newmeta-model (e.g., a modeling language) that would coversome specific application domains. Third layer is the modellayer (M1) that we can develop real-world models (ordomain models). In terms of UML models, that means cre-ating classes, their relations, states, etc. The bottom layer isinstance layer (M0). As MDA and its four-layer architectureprovide a solid basis for defining meta-models of any model-ing language (Duric, Gasevic, & Devedzic, 2005), OMG triesto define ontology meta-model based on MOF and four-layer architecture (Object Management Group, 2005).

2.2.2. Theoretic meta-layers

An ontology is a set of specialized terminology alongwith some specification of the meaning of terms in the lex-icon. While syntactic meta-layers are meta-layering fromthe viewpoint of modeling languages, another meta-layer-ing is from the viewpoint of semantics. Meta-layering ofsemantics is about ontology theory which defines meaningfor the terminology and a notion of truth for sentences ofthe language in terms of this ontology (Schlenoff et al.,2000). SBVR is an example of ontology theory (ObjectManagement Group, 2006).

The proposed theoretic meta-layers are based on SUO-IFF (SUO IFF) which has three layers: object layer,

Fig. 1. Ontology architecture.

2302 J. Lee et al. / Expert Systems with Applications 36 (2009) 2300–2309

meta-layer, and meta-shell. The object layer represents‘‘real world” concepts. The meta-layer in SUO-IFF is torepresent the intuitions and their ideas, while the meta-shellis to support the terminology in the natural part in confor-mance with the strong restrictions of the syntactic mecha-nism incorporated in the IFF grammar. The meta-shell inSUO-IFF is a kind of the syntactic meta-model of ontologytheory and this can be located at M2-layer in syntacticmeta-layers as described in Fig. 2. Namely ontology theoryis a kind of ontology which describes other ontology.

2.2.3. Domain layers by semantic domain ranges

The need of ontology layering by semantic domainranges is derived from the concept of upper ontology forintegration of ontology, as most of ontologies have targetdomains and their domain ranges are limited. To integrateontologies or enhance semantic sharing across ontologydomains, semantic interoperability across the ontologiesshould be supported. An upper ontology is introduced inorder to define foundational concepts used in more specificdomain ontologies (MITRE, 2004; OpenCyc; SuggestedUpper Merged Ontology). Because the upper ontology willprovide definitions for general-purpose terms, and it will

Fig. 2. Meta-layering about ontology.

act as a foundation for more specific domain ontology(Niles & Pease, 2001), the upper ontology is introducedas one axis in the ontology architecture. The example inFig. 3 is the domain layers of SBVR. The domain layersby semantic domains consist of domain independent,domain dependent, and domain specific layers.

Domain independent ontologies are the same concept asupper ontologies and provide basic concepts and relationswhich are adopted to domain dependent ontologies anddomain specific ontologies. As the domain independentontologies are often characterized as representing commonsense concepts, i.e. those that are basic for human under-standing of the world, concepts in the domain independentontologies are limited to those that are meta, generic,abstract and philosophical (Standard Upper OntologyWorking Group).

As same as mid-level ontology defined in SUO, adomain dependent ontology serves as a bridge between adomain independent ontology and a domain specific ontol-ogy. Domain dependent ontologies provide basic conceptsand relations to build domain specific ontologies as domain

Fig. 3. Ontology layers by semantic domains.

J. Lee et al. / Expert Systems with Applications 36 (2009) 2300–2309 2303

independent ontologies do. Domain specific ontologiesspecify concepts particular to a domain of interest andrepresent those concepts and their relations from a domainspecific perspective. Domain specific ontologies may bebuilt by importing or extending domain independent anddependent ontologies.

2.2.4. Constructive layers by basic constructs of ontology

Although concepts and relations are used as basic con-structs of ontologies, sometimes logics are added to expressmore clear relationships between the concepts and relations(Bittner, Donnelly, & Winter, 2005). If ontologies have dif-ferent additional constructs, the additional constructs canbe obstacles of interoperability among ontology. Because

Fig. 4. Constructive layering by constructs of ontology.

Fig. 5. Evolvin

the classification of ontologies’ constructs is needed tosolve this problem, constructive layers composed of fourconstructs are introduced as described in Fig. 4.

The constructs of ontologies are explained as follows(Halpin, 2001).

j Terms: A term defines basic and abstract idea that iscommonly used in an ontology domain. It is representedwith a word or phrase. For example, leg, humanbeing,earth, like, have.

j Facts: Facts are given by simple, declarative sentencesthat relate appropriate terms. Every fact is alwaysexpressed using a complete sentence, generally followinga strict subject(concept)–verb(relation)–object(concept)structure. This sentence provides a template, a struc-tured way to talk about how the terms logicallyconnected with each other. For example, have(human-being, leg) ? humanbeing have leg, live in(humanbeing,earth) ? humanbeing live in earth.

j Constraints: A constraint is the restriction that is appliedto the facts. For example, have(human, leg(==2)) ?humanbeing should have two leg, live in(humanbe-ing(max < 10 billion, earth) ? at most 10 billion human-being live in earth.

j Derivation rules: Rules, functions or operators (includ-ing mathematical calculation or logical inference) toderive new facts from other facts. For example, rule [ifit is humanbeing then it has two leg.] [if it is humanbeingthen it live in earth] ? derived fact: a man has two leg.A man lives in earth.

The constructive layers of ontologies can be a criterionof selecting ontology languages for building ontologies.

g ontology.

2304 J. Lee et al. / Expert Systems with Applications 36 (2009) 2300–2309

For example, if an ontology needs only terms and facts,resource description framework (RDF) (W3C, 2004) or

Fig. 6. Product ontol

Fig. 7. A procedure of building ontology u

topic maps (ISO/IEC, 2002) can be selected as an ontologymodeling language. If another ontology needs all

ogy architecture.

sing the product ontology architecture.

J. Lee et al. / Expert Systems with Applications 36 (2009) 2300–2309 2305

constructs, web ontology language (WOL) (W3C, 2004) orobject role modeling (ORM) (Halpin, 2001) can beselected.

3. Product ontology architecture

The function of design chain during the new productdevelopment phase is very important because more thantwo-thirds of all product lifecycle cost is determined duringthe conceptual design process (O’Marah, 2002). The designchain creates product information that is shared among thestakeholders and is maintained during product life cycle.Hence, the enterprises in the design chain must be capableof collaborating with each other. As product informationmay be gathered partly from multiple enterprises in thedesign chain, to effectively collaborate, the enterprisesshould share semantics related with products to avoidsemantic confusion causing time consuming work (Choiet al., 2005). For sharing semantics during collaboration,a product ontology should be built. However, becausethe product ontology evolves with time, the product ontol-ogy can be divided into two sub ontologies from the view-point of time; a static ontology and an evolving ontology.

Fig. 8. Dividing ontology into static and e

Static ontologies do not vary with time or they slowly varyduring very long time period. Because the static ontologiesare valid in a domain during very long time period, theycan be shared with all participants inbound and outboundof the domain guaranteeing interoperability. Product infor-mation can be changed during design process of products.Evolving ontologies reflect this changing feature of productinformation. Evolving ontologies cannot be shared withthe participants out of domain because they changescontinually.

Fig. 5 shows the examples of static, evolving, and mixedontologies. A fact ‘‘DC motor generates driving power” inthe static ontology is not changed with time. Therefore thefact can be always shared with the participants in and outof intended domain. On the other hand, in the evolvingontology, a concept ‘‘driving power” and a relation ‘‘gener-ate” are fixed, while a concept ‘‘DC motor” can be changedwith time: a fact changes from ‘‘DC motor generates driv-ing power” to ‘‘cylinder generates driving power”. Finally,it is changed to ‘‘AC motor generates driving power” withtime. These changes are caused by the undetermined factswhich very frequently occur in product development. Ifthe above mentioned facts are built in a domain and shared

volving ontology for washing machine.

2306 J. Lee et al. / Expert Systems with Applications 36 (2009) 2300–2309

with the participants out of the domain through integrationof ontology, the participants may share three undeterminedfacts in the integrated ontology. Because the facts in anevolving ontology are undetermined and are possible tobe changed, sharing the evolving ontology lead misunder-standing of the participants.

If the characteristic of two kinds of ontology are mixedin an ontology, we call the ontology as a mixed ontology asshown in Fig. 5. The mixed ontology is a more general kindof ontology in product development since some facts onproduct development are not changed during developinga product, while the other facts are changed during sameperiod. A fact ‘‘DC motor generates driving power”

belongs to the static ontology in the mixed ontology. Facts‘‘driving power”-‘‘act on”-‘‘spur gear”, ‘‘helical gear”, or‘‘herringbone gear” belong to the evolving ontology. Ifthe above mentioned facts are built in a domain, the staticontology can be shared with the participants out of thedomain while the evolving ontology is only shared in thedomain.

Fig. 9. Dividing ontology into static and

3.1. Product ontology architecture

Fig. 6 shows product ontology architecture extendedfrom ontology architecture suggested in this paper. Asshown in Fig. 6, there are five axes to reflect characteristicsof product ontologies: syntactic, theoretic, domain, con-structive, and evolving axis.

The syntactic meta-layers are the layers for ontologylanguages. They support syntactic interoperability acrossheterogeneous ontologies. Meta–meta and meta-ontologylayers in this axis can be or cannot be divided into staticor evolving layers. Meta–meta ontology and meta-ontol-ogy are the static ontologies. Ontology and instance layersin this axis can be divided into static or evolving layers.

The theoretic meta-layers support semantic interopera-bility of ontology itself as explained in previous chapter.Ontology theory can be or cannot be divided into staticor evolving layers. If ontology theory is divided into a sta-tic ontology theory and an evolving ontology theory, twotheories should provide converting axioms from a static

evolving ontology for automobile.

J. Lee et al. / Expert Systems with Applications 36 (2009) 2300–2309 2307

ontology to an evolving ontology and vice versa, since astatic ontology can be changed into an evolving ontologyand an evolving ontology can be changed into a staticontology.

The domain layers are the layers by semantic domainrange. They support semantic interoperability across heter-ogeneous ontologies. All layers in this axis can be dividedinto static or evolving layers.

The constructive layers are the layers by constructs ofontology. They support constructive interoperability acrossheterogeneous ontologies. All layers in this axis also can bedivided into static or evolving layers.

The ontology architecture does not only enhance inter-operability among ontology but also has additional advan-tages. It helps selection of a pertinent ontology languagethrough the definition of characteristics of ontologies and

Fig. 11. A scenario of interoperation

Fig. 10. Interoperations among ontology languages using ODM andmeta-layering.

provides a criterion of sharable (static) or un-sharable(evolving) ontologies.

3.2. Exemplary scenarios

In this section, a building procedure of product ontolo-gies in e-commerce environment is described as an applica-tion example. And a simple scenario for the collaborationof enterprises through the integration of heterogeneousontologies is illustrated as an example about guaranteeinginteroperability using the product ontology architecture.

Fig. 7 describes a procedure of building product ontolo-gies for washing machine and automobile. The detailedprocedure of building static and evolving ontology areexplained as follows.

j Select a domain dependent ontology as a referenceontology of the domain ontology. Washing machineontology and automobile ontology select mechanicaldomain ontology as a domain dependent ontology.

j Divide the ontologies into static and evolving ontology.Static ontology is valid until the ontology is effective. Itis sharable ontology. Evolving ontology may be tempo-rary ontology. It is valid only at some moment fromsome viewpoint. Because mixing the static and evolvingontology leads to misunderstanding, static and evolvingontology should be divided. In this step, the target ontol-ogies are divided into static ontologies and evolvingontologies. Figs. 8 and 9 show this dividing of ontologies.

using the integration of ontology.

Fig. 12. Domain integrated ontology according to the purpose – all constructs.

2308 J. Lee et al. / Expert Systems with Applications 36 (2009) 2300–2309

j Select constructs of ontology which are used to buildthem. The washing machine ontology needs all con-structs and the automobile ontology only needs termsand facts.

j Select theories of ontology which are used to build them.The ontology theories provide basic semantic irrespec-tive of languages. Set theory is a basic theory of themechanical domain ontology and is applied to the wash-ing machine ontology and the automobile ontology.First order theory is selected as a basic theory of thewashing machine ontology and subject based theory isselected for the automobile ontology. The selection stepof ontology theories can be applied on both static ontol-ogy and evolving ontology.

j Select a pertinent ontology language. For guaranteeinginteroperability among ontology languages, the selectedontology languages should be interoperable to ontologydefinition meta-model (ODM) (Object ManagementGroup, 2005). ODM supports the interoperabilityamong ontology language through M2 layer of themeta-layers in the ontology architecture as describedin Fig. 10. The washing machine ontology selects

Fig. 13. Domain integrated ontology according to the purpose – conceptsonly.

OWL and the automobile ontology selects topic mapsconsidering interoperability to ODM, the constructs ofontology, and ontology theory.

j Build domain specific ontologies using the selected lan-guage. Right-down sides of Figs. 8 and 9 show domainspecific ontologies of washing machine and automobile.

3.3. Interoperation using the integration of ontology

Fig. 11 describes a scenario for the collaborationbetween the washing machine company and the automo-bile company through integrating domain specific ontolo-gies into a domain integrated ontology.

The domain integrated ontology for two companiesbased on the product ontology architecture is describedin Figs. 12 and 13.

4. Conclusion

Ontologies are expected in various areas as promisingtools to improve communication among people and toachieve interoperability among systems. Especially ontolo-gies for sharing product information across design chaincan play important role since amount of cost caused bymisunderstanding occurs during product design process.

To facilitate building product ontology, we suggest theproduct ontology architecture. As a basis, we proposedthe generic ontology architecture first. The proposed gen-eric ontology architecture consists of four axes: syntacticaxis, theoretic axis, domain axis, and constructs axisaccording to viewpoints.

Because product ontologies evolve with time, the prod-uct ontology architecture should reflect evolving featureto guarantee interoperability. In this paper, we proposethe product ontology architecture which includes evolvingaspect of product ontology in addition to the proposedgeneric ontology architecture. Thus, product ontology

J. Lee et al. / Expert Systems with Applications 36 (2009) 2300–2309 2309

architecture has a new axis: evolving axis. Evolving axisconsists of static and evolving layers. Through a procedureof building ontology using the product ontology architec-ture, our proposed product ontology architecture can beapplied for developing integrated ontology for washingmachine and automobile. For the future work, we willdevelop an architecture based collaboration method thatsupports agile collaboration through semantic synchroni-zation by using product ontology architecture, as sharingsemantics makes product information between participantsto be interpreted with a same meaning.

Acknowledgement

This work was supported by Grant no. R01-2007-000-11040-0 from the Basic Research Program of the KoreaScience and Engineering Foundation.

References

Bittner, T., Donnelly, M., & Winter, S. (2005). Ontology and semanticinteroperability. In Large-scale 3D data integration. London: CRCPress.

Choi, Y., Kim, K., & Kim, C. (2005). A design chain collaborationframework using reference models. International Journal of Advanced

Manufacturing Technology, 26(1), 183–190.Duric, D., Gasevic, D., & Devedzic, V. (2005). Ontology modeling and

MDA. Journal of Object Technology, 4(1), 109–128.Gruber, T. (1993). Toward principles for the design of ontologies used for

knowledge sharing, Technical Report KSL93-04, Knowledge SystemsLaboratory, Stanford University.

Guarino, N. (1998). Formal ontology in information systems. InProceedings of formal ontology in information systems (FOIS’98) (pp.3–15). Trento, Italy.

Halpin, T. (2001). Information modeling and relational databases: From

conceptual analysis to logical design. San Francisco: Morgan-Kaufmann.

Halpin, T. (2001). Object-role modeling: An overview, ORM Whitepaper,<http://www.orm.net/ pdf/ORMwhitePaper.pdf>.

ISO/IEC (2002). ISO/IEC 13250 Topic Maps (2nd ed.). ISO/IEC 13250Standard, <http://y12web2.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd- ed-v2.pdf>.

Jagdev, H. S., & Thoben, K. D. (2001). Anatomy of enterprisecollaboration. Production Planning and Control, 12(5).

Jasper, R., & Uschold, M. (1999). A framework for understanding andclassifying ontology applications. In Proceedings of the IJCAI99

workshops on ontologies and problem-solving methods. Sweden:Stockholm.

Kalfoglou, Y., & Schorlemmer, M. (2002). Information-flow-basedontology mapping. Lecture Notes in Computer Science, 2519,1132–1151.

Lee, J., Chae, H., Kim, K., & Kim, C. (2006). An ontology architecture forintegration of ontologies. Lecture Notes in Computer Science, 4185,205–211.

MITRE (2004). Toward the use of an upper ontology for US government

and US military domains: An evaluation, MITRE Technical Paper,<http://www.mitre.org/work/tech_papers/ tech_papers_04/04_0603/04_1175.pdf>.

Niles, I., & Pease, A. (2001). Towards a standard upper ontology. InProceedings of the second international conference on formal ontology in

information systems (FOIS-2001) (pp. 2–9). USA: Ogunquit.Noy, N., & Hafner, C. (1997). The state of the art in ontology design – A

survey and comparative review. AI Magazine, 36(3), 53–74.Object Management Group. (2002). Meta object facility (MOF) specifi-

cation Version 1.4, OMG Document: formal/2002-04-03, <http://www.omg.org/docs/formal/02-04-03.pdf>.

Object Management Group. (2005). Ontology definition metamodelrequest for proposal, OMG document: ad/2003-03-40, <http://www.omg.org/docs/ad/03-03-40.pdf>.

Object Management Group. (2006). Semantics of business vocabulary andbusiness rules (SBVR) 2nd SBVR interim specification, OMG docu-ment: dtc/06-08-05, <http://www.omg.org/docs/dtc/06-08-05.pdf>.

O’Marah, K. (2002). PDM + ERP = PLM: TIBCO and PTC Join toMake This a Little Easier, AMR Research Alert.

OpenCyc Website. <http://www.opencyc.org/>.Perrin, O., & Godart, C. (2004). A model to support collaborative work in

virtual enterprises. Data and Knowledge Engineering, 50.Pisanelli, D., Gangemi, A., & Steve, G. (2002). Ontologies and informa-

tion systems: The marriage of the century? In Proceedings of the LYEE

workshop. Paris, France.Schlenoff, C., Gruninger, M., Tissot, F., Valois, J., Lubell, J., & Lee, J.

(2000). The process specification language (PSL): Overview and

Version 1.0 specification, NISTIR 6459, National Institute of Stan-dards and Technology, Gaithersburg.

Semantic Interoperability Community of Practice(SICoP) Website.<http://web-services.gov/ -SICOPsemwave2006v1.0.pdf>.

Standard Upper Ontology Working Group Website. <http://suo.ieee.org/>.

Suggested Upper Merged Ontology Website. <http://ontology.teknowl-edge.com/>.

The SUO Information Flow Framework (SUO IFF) Website. <http://suo.ieee.org/IFF>.

Uschold, M., & King, M. (1995). Towards a methodology for buildingontologies. In Proceedings of IJCAI95 workshop on basic ontological

issues in knowledge sharing. Montreal, Canada.W3C. (2004). OWL Web Ontology Language Guide, W3C Recommen-

dation, <http://www.w3.org/TR/2004/REC-owl-guide-20040210/>.W3C. (2004). RDF Primer, W3C Recommendation, <http://www.w3.org/

TR/2004/REC-rdf-primer-20040210/>.