Towards a general ontology of configuration

Towards a general ontology of configuration

TIMO SOININEN, JUHA TIIHONEN, TOMI MÄNNISTÖ, and REIJO SULONENHelsinki University of Technology, TAI Research Centre and Laboratory of Information Processing Science, Helsinki, Finland

(Received October 31, 1997;Accepted February 5, 1998!

Abstract

This article presents a generalized ontology of product configuration as a step towards a general ontology of config-uration, which is needed to reuse and share configuration knowledge. The ontology presented consists of a set ofconcepts for representing the knowledge on a configuration and the restrictions on possible configurations. The ontol-ogy is based on a synthesis of the main approaches to configuration. Earlier approaches are extended with new conceptsarising from our practical experience on configurable products. The concepts include components, attributes, re-sources, ports, contexts, functions, constraints, and relations between these. The main contributions of this work are inthe detailed conceptualization of knowledge on product structures and in extending the resource concept with contextsfor limiting the availability and use of resources. In addition, constraint sets representing different views on the productare introduced. The ontology is compared with the previous work on configuration. It covers all the principal ap-proaches, that is, connection-based, structure-based, resource-based, and function-based approaches to configuration.The dependencies between the concepts arising from different conceptualizations are briefly analyzed. Several ways inwhich the ontology could be extended are pointed out.

Keywords: Configuration Design; Product Configuration; Ontology; Conceptual Analysis; KnowledgeRepresentation

1. INTRODUCTION

Configuration has been a fruitful topic of research in arti-ficial intelligence for the past two decades. In the last fiveyears, configuration has also become a commercially suc-cessful and important application of artificial intelligencetechniques.Configurationas a task can be roughly definedas the problem of designing a product using a set of pre-defined components while taking into account a set of re-strictions on how the components can be combined. The termproduct configurationis used to denote the routine engi-neering activity of this type in the sales-order-delivery pro-cess. The termconfiguration designmay also encompassmore design-oriented activities that take place in the prod-uct development process.

Most of the research on configuration has concentratedon problem-solving methodologies, such as constraint sat-isfaction ~e.g., Mittal & Falkenheiner, 1990!, resource-based configuration~Heinrich & Jüngst, 1991!, and propose-

and-revise type approaches~e.g., Balkany et al., 1993!.Despite the research on various problem-solving tech-niques, a general ontology of configuration domain has notemerged. We think that defining a general ontology of con-figuration ~Gruber, 1995! is an equally important researchissue.

The importance of a general ontology of the configura-tion domain lies in facilitating reuse of the knowledge onconfigurable products and cooperation between different con-figurator agents based on different problem-solving meth-odologies in configuring a product~Wielinga & Schreiber,1997!. An ontology can also be used as a basis for docu-menting configuration knowledge in an easy-to-understandform. We believe the research on configuration would bene-fit from the common ground provided by a general ontology.

This paper aims at providing some steps on the road to-wards a general ontology of the configuration domain. Theontology presented synthesizes and extends earlier ap-proaches. It contains a detailed conceptualization of the com-positional structure of a product. The ontology integratesresource-based concepts to other approaches through ex-tending the resource concept with contexts. Unlike earlierwork, it also treats the concepts uniformly with respect to

Reprint requests to: Timo Soininen, Helsinki University of Technology,TAI Research Centre and Laboratory of Information Processing Science,P.O. Box 9555, FIN-02015 HUT, Finland. E-mail: [email protected].

Artificial Intelligence for Engineering Design, Analysis and Manufacturing~1998!, 12, 357–372. Printed in the USA.Copyright © 1998 Cambridge University Press 0890-0604098 $12.50

357

refinement and abstraction. Constraint sets are introducedto capture different points of view on the correctness of aconfiguration.

The ontology presented is a unified informal ontology forconfiguration domain. It is by no means the only correctontology or necessarily general enough to capture all therelevant knowledge. We take a product-configuration pointof view. This means that the ontology may not cover all thethings required for configuration design. The ontology doesnot cover the knowledge related to the geometry, pricing, oroptimality of configurations, either. These types of knowl-edge are often important for product-configuration tasks. Nordoes the ontology include the construction and controlknowledge on how to accomplish the configuration task, thatis, what actions and in which order can be taken to config-ure a product~Cunis et al., 1989!.

In Section 2, we discuss the method for specifying theontology. In Section 3, we present the basic definitions ofthe ontology. The different concepts in the ontology are dis-cussed in Section 4. Our ontology is discussed in relation toprevious work in Section 5. Finally, in Section 6 conclu-sions are given and topics for future work are discussed.

2. METHOD

The earlier conceptualizations of configuration knowledgecan be roughly classified toconnection-based~Mittal &Frayman, 1989!, resource-based~Heinrich & Jüngst, 1991!,structure-based~e.g., Cunis et al., 1989!, and function-based~Najman & Stein, 1992! approaches. The approacheshave presented more or less explicitly a set of method-specific concepts for representing product knowledge neededin configuration problem solving. The conceptualizationshave little in common except the central notion of acomponent.

Our aim is primarily to provide an ontology for the re-quired forms of knowledge and its representation in a com-puter and only secondarily to provide computer support forconfiguration tasks. The concepts in the ontology have notbeen influenced by considerations of computational com-plexity of configuration task, although this is an importantresearch issue on its own. Our ontology tries to be as method-independent as possible.

We try to synthesize the four approaches mentioned above,as they all seem to have gained at least some acceptance inthe research community or have been used in commercialapplications. Our own experiences on configurable prod-ucts have led us to believe that all four types of modellingconcepts are needed to compactly and adequately representthe knowledge on products~Tiihonen, 1994; Tiihonenet al., 1996!.

When discussing an ontology, it is necessary to separateentities that occur in a configuration model or configurationof a particular product from meta-entities that are used todescribe what the entities are. We base our ontology on the

Frame Ontology of Ontolingua~Gruber, 1992!. We nextbriefly describe the Frame Ontology. The basic concepts inFrame Ontology areclasses, instances, relations, andfunc-tions. These can be defined to have properties, such as in-stances of a particular class are always in some relation or aparticular relation is transitive. Classes collect together thedefinitions that apply to all their instances. A classC1 issaid to be asubclassof classC2 if and only if every poten-tial instance ofC1 is also an instance ofC2. The subclass-relation induces ataxonomyin which the definitions aremonotonically inherited. A superclass-relation betweenclasses is defined as the inverse of subclass in the obviousway. An instanceI is said to be adirect instance of a classC1 if there is no classC2 such thatC2 is a subclass ofC1 andI is an instance ofC2. A directsubclass is defined similarly.For a more detailed account of Ontolingua, we refer to~Gruber, 1992!.

3. FOUNDATIONS OF THECONCEPTUALIZATION

Our ontology forconfiguration knowledge, that is, the knowl-edge that people have on configurable products, is based onthe knowledge needed when configurable products are de-fined and configuration problems are solved. We distin-guish between the following three classes of configurationknowledge. They exist independently of the problem solv-ing methods.

Configuration model knowledgespecifies the entities thatmay appear in a configuration, their properties, and the ruleson how the entities and their properties can be combined.Configuration model knowledge contains all the informa-tion for tailoring the product to meet given requirements. Inother words, configuration model knowledge specifies theset ofcorrect1 configurations of a product with respect tothe configuration model and requirements.

Configuration solution knowledgespecifies a~possiblypartial! configuration. A configuration specifies in suffi-cient detail what a real-world product instance must be like.A partial configuration leaves some aspects about the real-world product instance open.

Requirements knowledgespecifies requirements on theconfiguration to be constructed. Requirements knowledgecan in our view be specified with the same concepts as con-figuration model knowledge and configuration solutionknowledge, although it plays a different role in problem solv-ing ~Wielinga & Schreiber, 1997!. For this reason, we ex-plicitly discuss only configuration model knowledge andconfiguration solution knowledge.

An ontology tries to define a set of concepts to representknowledge. An ontology is needed to document the knowl-edge, to store it into a computer, or to make inferences. Our

1We omit here the precise definition of a “correct” configuration. For amore detailed analysis of the correctness of a configuration with respect toa subset of this conceptualization, we refer to Peltonen et al.~1998!.

358 T. Soininen et al.

ontology of configuration knowledge has the following ba-sic structure~Figure 1!2. We define a set ofconfigurationmodel conceptsas a top-level taxonomy ofconfigurationspecific classesand a set ofconfiguration specific relationdefinitions. Distinguished configuration domain specificclasses includeconstraintandproperty definition.

A configuration modelof a particular product is definedas a set ofproduct specific classesand a set of constraintand property definition instances. The product specificclasses are direct subclasses of the configuration specificclasses. We call thesetypes to distinguish them fromgeneric Ontolingua classes. Since we are interested in pro-viding information system support for representing theknowledge, a representation of a configuration model as wellas a configuration must be finite.

A configurationof a product with respect to a given con-figuration model is defined as a set of instances of the typesoccurring in the configuration model. We call such in-stancesindividuals to separate them from the generic On-tolingua instances. In addition, a configuration includesconfiguration specific relations, calledproperties, betweenthe individuals.

Note that configuration specific classes do not occur in aconfiguration model of a particular product. Direct in-stances of configuration specific classes do not occur in aparticular configuration, either. Unless otherwise stated, theconfiguration specific classes introduced are considered dis-joint, that is, their instances are two disjoint sets. The con-figuration specific subclasses also cover their superclasses.This means that there are no instances that are instances of

the superclass but not instances of any of its subclasses. Notethat types are not required to cover their supertypes.

Individuals in a correct configuration~with respect to agiven configuration model! must have the properties spec-ified by their types. In this case, we say that an individual isvalid with respect to its type. A correct configuration mustalso satisfy the constraints in the configuration model. Whendescribing the concepts, we often use the words “must”, “is”,and “may” to specify certain restrictions. The intended mean-ing of these restrictions is that they hold in a correct config-uration. If these restrictions do not hold, a configuration isincorrect. For simplicity, we do not consider the validity oftypes and their property definitions. We assume that the typesand their properties in a configuration model are valid withrespect to the classification taxonomy in the configurationmodel, that is, that the properties are inherited properly andthat all the subclass-relations are explicitly presented.

The concepts of types, property definitions, constraints,individuals, and properties of individuals are defined in moredetail in the next section. Figure 2 gives an overview of theclasses and the taxonomy of the ontology. We make the ty-pographical convention that the concepts in our ontologyare typeset insmall capitals when they are defined.

4. CONCEPTS

4.1. Taxonomy

In this section, we give basic definitions for the concepts inconfiguration model knowledge and configuration solutionknowledge. We introduce the concepts of a type and an in-dividual to distinguish between the entities that occur in con-figuration model knowledge and configuration solutionknowledge. Types are further organized in classification

2We use the Universal Modeling Language~UML ! notation in the fig-ures~Fowler, 1997!. The legend for the notation in Ontolingua terms isgiven in Figure 1.

Fig. 1. Basic structure of the ontology.

General ontology of configuration 359

taxonomies to enable compact representation of the knowl-edge common to different types, which is important for main-taining the knowledge. The class configuration type isintroduced to gather the definitions common to some of theclasses in our ontology. Direct subclasses of configurationtype do not occur in a configuration model.

Configuration knowledge is commonly discussed usingterms that do not distinguish between configuration modelknowledge and configuration solution knowledge. For ex-ample, the sentence “Car has an engine as a part” can be in-terpreted in two ways.As configuration model knowledge thesentence can be understood as saying that every car indi-vidual must have an engine individual as a part. As config-uration solution knowledge, it states that a configuration

includes a car individual that has an engine individual as apart. We want to clearly separate these meanings by using theterms type and individual. Subclasses ofconfigurationtype, that is, types, occur in the configuration model. A typespecifies intensionally the properties that all valid individu-als of that type must have throughproperty definitions.Anindividual is an entity that occurs in the configuration.

Types have a classification taxonomy with inheritance de-fined by isa-relation between types. The semantics of thetaxonomy and inheritance are related to the direct-subclass-of-relation of Ontolingua as follows:~T1 isaT2! implies~T1

direct-subclass-ofT2!. We distinguish between thedirect isa-relation and thetransitiveisa-relation similarly as the direct-subclass-of and subclass-of relations in Ontolingua. We refer

Fig. 2. Overview of the classes and their taxonomy in the ontology.~a! The main concepts.~b! Property definitions that can be givento configuration types.~c! Further classes that are used in property definitions.


to subtypes and supertypes similarly as in Ontolingua to sub-classes and superclasses. Unlike in Ontolingua, the taxon-omy is explicitly represented through the isa-relation and“incidental” subclass-relations are not allowed. That is,~T1

direct-subclass-ofT2! does not necessarily imply~T1 isaT2!.We also require that the taxonomy is well-formed in the sensethat it does not contain cycles. In other words, the transitiveclosure of the isa-relation must be antisymmetric and anti-reflexive. Note that we allow multiple inheritance.

A subtype mayrefine the property definitions it has in-herited. Refinement of property definitions is semanticallybased on the notion that the set of potential valid individu-als directly of the subtype is smaller than the set of validindividuals directly of the supertype.

An individual is directly of exactly one type. Simi-larly as in Ontolingua, an individual isindirectly also of allsupertypes of its type. A valid individual of a type is de-fined to be directly of the type and an instance of the type~in Ontolingua terms!.

Each type is either abstract or concrete. This is specifiedthrough anabstraction definition. An individual di-rectly of aconcrete typeis accurate enough to be used in anunambiguous configuration. An individual directly of anab-stract typeprovides only partial information on the real-world entity it represents. Abstract types naturally emergewhen the knowledge common to a set of types are gatheredin a supertype. A configuration that includes individuals di-rectly of abstract types must be refined so that a final con-figuration contains only individuals directly of concretetypes. It is a modelling decision which types are consideredabstract and which concrete. Note that we do not assumethat a valid individual of a concrete type would have fixedattribute values, for example. A concrete type may still al-low variation in the properties of the individual. The ab-straction definition is not inherited. It defines a property ofdirect individuals of the type only.

Each minimal~leaf! element in a taxonomy must be con-crete. If there were an abstract type as minimal element inthe taxonomy, then no individual of that type could ever beused in an unambiguous specification of a product.

Example. We shall use a running example for demon-strating the concepts we define. The sample product, Hos-pital Monitor ~HMonitor!, is loosely based on a successfulreal-word configurable product for clinical measurements.We have simplified the product considerably and altered itto emphasize some aspects of it.

Figure 3 shows the taxonomy of the types in the config-uration model of the monitor. The arrows denote the isa-relation between different types. Some properties of the typesare given in brackets next to the type. Note that for instancethe type Module is abstract and therefore an individual di-rectly of module may not occur in an accurate configura-tion. Such an individual must be refined to be of one of theconcrete subtypes of Module. The meaning of the “ind” and“dep” definitions are explained in Section 4.3. n

4.2. Attributes

Attributes represent the characteristics of the type. Typeshave attribute definitions that specify the possible valuesthat attributes of valid individuals may have.

A configuration type specifies a set of attributes bymeans of anattribute definition, which consists of anattribute name, an attribute value type, and ane-cessity definition. This is an example of a property def-inition. When a configuration type has an attribute definition,a valid individual of the configuration type has anattributeaccording to the attribute definition and either exactly one~necessaryattribute! or at most one~optional attribute!attribute value of the attribute value type. One particu-larly important attribute type isphysical quantity ~Gru-ber, 1995! such as length or mass. As usual, attribute valuetypes are considered classes and attributes are consideredrelations between individuals and instances of attribute valuetypes ~Gruber, 1992!. A configuration model must definethe instances that an attribute value type has. To representan attribute without a value, the special instanceundefinedmust be included in every attribute value type. The attributevalue type or necessary0mandatory definition defined in asupertype may be refined in a subtype.

Example. Figure 4 presents property definitions of thetypes in our sample configuration model. In the propertydefinitions, we typeset the names of concepts and other re-served words inbold. We abbreviate some of the terms tosave space. The property definitions are presented using avery simple syntax. This syntax is by no means intended forreal modelling tasks3. The syntax consists of sentences whichare defined as a sequence of a type name, name of the def-inition given, and a definition delimited by brackets. A sen-tence is ended by a semi-colon. The definition may consistof several parts separated by commas. We use curly bracesto indicate elements of definitions that are sets. Under “Tax-onomy”, two attributes color and surface material are de-fined for the monitor. Attribute types and their attribute valueinstances are also defined. An individual of HMonitor musthave a value for both the attributes since they are necessary.One can also use standard attribute value types such as in-tegers, which are assumed to have an appropriate standarddefinition. The simple constraintc1associated with HMon-itor restricts the combinations of the attribute values so thatone cannot have a monitor with material plastic and colormetal. n

4.3. Structure

In this section, we define component types, component in-dividuals, and their compositional structure as the basic con-

3A real modelling language should, in the tradition of object-orientedlanguages, collect all the definitions pertaining to one type under one type-definition to facilitate easier maintenance of the knowledge. We use thistype of syntax in the example to follow more closely the order in whichconcepts are introduced.


cepts for representing configuration model knowledge andconfiguration solution knowledge. The compositional struc-ture is important for configuration because products arecommonly described through their structure for design, manu-facturing, or maintenance purposes.

A component type represents a distinguishable entityin a product that is meaningful for product configuration in

the sense that a configuration is composed ofcomponentindividuals of component types. Component type is a sub-class of configuration type.

A component type specifies the parts of a valid compo-nent individual of the component type through a set ofpartdefinitions. The parts are realized with component indi-viduals. A part definition specifies apart name, a set of

Fig. 3. Configuration model for hospital monitors.~a! Component type taxonomy.~b! Port, resource, and attribute value type tax-onomy.~c! Function type taxonomy and the constraints.


possible part types, acardinality, anexclusivity def-inition, and ahas-part inheritance definition. Whendiscussing a particular part definition, we refer to the com-ponent type that defines its parts as thewhole type.

A component type may occur as a part type in severaldifferent part definitions of one component type under dif-ferent part names or in several different part definitions ofdifferent component types. A component type may refineits inherited part definitions by restricting the set of parttypes, the cardinality or has-part inheritance definition.

A part name distinguishes the role in which different com-ponent individuals are parts of a component individual ofwhole type. The part types indicate the component typeswhose component individuals are allowed to occur as partswith the associated part name. A cardinality specifies howmany component individuals must occur as parts with thepart name.

The exclusivity definition specifies that a part is eitherexclusiveor shared. A valid exclusive part, that is, a com-ponent individual occurring as a part with a name that in-

Fig. 4. Property definitions of the types in Figure 3.


dicates it as exclusive, must not occur as a part of anothercomponent individual. In the shared case there is no suchrestriction. When modelling a physical product, it is usuallyreasonable to assume that one valid component individualis a part of at most one component individual. Some ab-stract entities such as services or software may be shared.

A has-part inheritance definition is a special constraint~see Section 4.8!. It specifies how the properties of compo-nent individuals of whole types are dependent on the prop-erties of parts andvice versa. These dependencies can bestraightforward, such as parts inheriting the color of thewhole, or they may be more complex, such as the weight ofthe whole being the sum of the weights of its parts.

The semantics of a part definition is that a valid compo-nent individual of the whole type has the number of com-ponent individuals specified by the cardinality as parts withthe specified part name. Each part must be of one of thepossible part types and obey the exclusivity and has partinheritance definitions. The fact that a component individ-ual has another component individual as a part is concep-tualized as ahas-part-relation between the componentindividual that has the part, component individual that isthe part, and the part name.

The part definitions are meant to define thedirect partsthat a valid component individual of the component typehas. The has-part-relation must be antisymmetric and anti-reflexive to exclude nonintuitive configurations in whichcomponent individuals are direct parts of each other or ofthemselves.

In some cases, it is also necessary to refer totransitiveparts of a component individual given by thetransitivehas-part-relation defined as the transitive closure of has-part relation. Transitive has-part-relation must also be anti-symmetric and antireflexive.

A component type has two special properties that, likethe abstraction definition, are not inherited by its subtypes.The first is adependency definition. A component typeis eitherdependentor independent. A valid component in-dividual directly of an independent component type may ex-ist in a configuration without being a part of something, whilea valid component individual directly of a dependent typemay not. This distinction is made to indicate that only com-ponent individuals directly of particular component typesmay be the roots of the compositional structure. Some com-ponent types are by nature such that individuals of them donot function properly or at all without being a part of some-thing else. The second is anexclusivity definition, whichis the same as the one introduced in part definition, with theexception that it applies globally.

Example. In the example all component types are phys-ical entities and therefore exclusive, so we omit the exclu-sivity definitions ~Figure 3a!. Only the component typeHMonitor is defined as independent~in the definition nextto the component type in the figure!. Therefore, only an in-dividual of HMonitor can occur as a root of the has-part

hierarchy of component individuals. HMonitor has the partswith part names base part, primary display, secondary dis-play, secondary-display-adapter, and module~see “Struc-ture” in Figure 4!. Base part is of type base-unit and anindividual of HMonitor must always have one base part.The primary display may be of types Disp-10 or Disp-14,that is, a 10-inch or 14-inch display. HMonitor may haveone or two primary displays. The secondary display adapterand secondary display are optional parts of HMonitor, sincethe cardinality definitions for these includes the value zero.

The constraintsc3 andc4 on possible connections underthe heading “Topology” in Figure 4 demonstrates the needto refer to a certain part by its part name, without knowingthe component type that the actual part will be an individ-ual of.

None of the component types have has-part inheritancedefinitions, so we omit these from the definitions. An ex-ample of a has-part inheritance definition in the context ofthis example could be that Module also had a color attributedefinition and the value of this attribute would have to bethe same as the color of the monitor. n

4.4. Topology

In this section, we define the topological concepts of a porttype and a port individual that represent how componentindividuals can be connected together to form a workingproduct~Mittal & Frayman, 1989!. Connections can be phys-ical or logical. Port definitions represent the compatibilityof component individuals and specify the possible topolo-gies of the product.

A port type is an intensional definition of a connectioninterface. Port type is a subclass of configuration type. Aport individual represents a “place” where in a compo-nent individual some other port individual may be con-nected to. A port type has acompatibility definition thatdefines a set of port types whose port individuals can beconnected to the port individuals of the port type. In addi-tion, a port type defines a set ofconnection constraints.Only port individuals that satisfy the connection constraintsdefined by their port types may be connected to each other.A connection constraint may also specify that port individ-uals with given attribute values and of particular type mustbe connected. Connection constraints are a special case ofconstraints~see Section 5.7! that refer only to port and com-ponent types, their individuals and their attributes andattribute values.

A component type specifies its connection possibilitiesby port definitions. A port definition specifies aportname for the port, aset of possible port types, a car-dinality, and connection constraints. A port definition canrefine the set of compatible port types from those specifiedby the port type or those specified by a supertype of thecomponent type. It can also specify additional connectionconstraints. Cardinality may also be refined.


Example. In our example there are two abstract porttypes, Video-in and Video-out~Figure 3b!. These have con-crete subtypes for standard resolution displays~VGA! andhigh-resolution displays~XGA!. Video-out is defined tobe compatible with Video-in andvice versa~“Topology” inFigure 4!. They have no connection constraints. Thus, anyport individuals directly of these types may be connected.VGA-out inherits the compatibility with Video-in fromVideo-out and XGA-in inherits the compatibility with Video-out from Video-in. The compatibility definition is refinedfor the XGA-out so that it is only compatible with XGA-in.Similarly, VGA-in refines the compatibility to VGA-out.In effect, an XGA-out port individual can be connected toan XGA-in port individual only, a VGA-out port individualto individuals of both Video-in subtypes, an XGA-in portindividual to port individuals of both Video-out subtypes,and an VGA-in port individual only to a VGA-out portindividual.

An individual of base-unit has two display-out port indi-viduals of VGA-out type. There is a connection constraintc3attached to this port definition that if there is a base-unitand a primary display in the configuration, then a display-out of base-unit and the signal-in of primary display mustbe connected. An XGA-display adapter similarly has onedisplay-out of XGA-out type, which must be connected tothe signal-in of the secondary display~constraintc4!. Asimplied above, a display unit has one signal-in port of typeVideo-in. This port definition is inherited by the 10-, 14-,and 21-inch display component types and refined to eitherVGA-input ~10- and 14-inch! or XGA-input ~21-inch!. Thefact that a property specification is a refinement and doesnot introduce a new property is implied by using the sameproperty~part, port, etc.! name as in a supertype. These def-initions together state that a hospital monitor has one ortwo VGA primary displays~10- or 14-inch! connected tothe base-unit and possibly a secondary XGA~in this exam-ple the 21-inch only! display connected to the XGA displayadapter. n

A port definition specifies that a valid component indi-vidual of the component type has the number of port indi-viduals specified by the cardinality with the given port name.The port individuals must be of the appropriate port types.This is conceptualized as the component individual, the portindividual, and the port name being inhas-port-relation.A port individual cannot exist in a configuration withoutbeing associated with a component individual.

Two component individuals that have port individuals ofcompatible port types may be connected to each otherthrough their port individuals if the port and component in-dividuals satisfy the connection constraints. This is concep-tualized as the two port individuals being inconnectedto-relation. Two component individuals are connected toeach other, represented by them being in theconnectedto-relation, if some of their port individuals are in the con-nected to-relation. At most, one port individual can be con-

nected to a port individual. Both connected to-relations aresymmetric and antireflexive to prevent a port individual anda component individual from being directly connected toitself. The intended meaning is that port individuals repre-sent the places at which two different component individu-als can be connected to each other. Port individuals of onecomponent individual cannot be connected to each otherwithout another component individual and its attendant portindividuals.

Similarly to has-part-relation, it is sometimes necessaryto refer to the component or port individuals that aretran-sitively connected to each other, that is, that are in thetransitive closure of the connected to-relation.

4.5. Context

In this section, we define a natural way of restricting theapplicability of certain pieces of knowledge to certain “parts”of the configuration. This restriction is defined as a contextin which the piece of knowledge holds. The context con-cept will be used in Section 4.6 to enrich resource-orientedconcepts.

When specifying a configuration model, often some thingsin the model are true only in a certaincontext. We definea context as a set of component individuals in a configura-tion. There are three natural contexts that arise from the con-cepts introduced above:

• component type set context, defined as the set ofindividuals in a configuration that are of the compo-nent types in a given set of component types.

• mereological context, defined as consisting of acomponent individual and the set of component indi-viduals that are its parts.

• topological context, defined as consisting of a com-ponent individual and the set of component individu-als that are connected through port individuals to it.

We distinguish between animmediate mereologicalcontext and atransitive mereological context. Animmediate mereological context contains the component in-dividuals that are direct parts of the component individualthat specifies the context. A transitive mereological contextcontains also the component individuals that are transi-tively parts of the component individual that specifies thecontext. Two individuals of the same type are not necessar-ily in the same mereological context, as they need not beparts of the same larger whole. Analogously to the mereo-logical contexts, we define animmediate topological con-text and atransitive topological context.

A context is specified by acontext definition. A con-text definition consists of a set of component types~com-ponent type set context!, or a component type and thedefinition whether the parts or connected component indi-viduals of the component type form the context, and whetherthe context is immediate or transitive. These are referred to


asatomic contexts. A context specification may also be aunion or intersection or complement with respect to eachother of any number of atomic contexts. Theunion of twocontextsis the context formed by the union of the sets ofcomponent individuals in the two contexts.Intersection andcomplement of two contextsare defined similarly.

4.6. Resources

In this section, we define the resource-oriented concepts,which are needed for modelling the production and use ofsome more or less abstract entity or the flow of such entitiesfrom one component individual to another~Heinrich &Jüngst, 1991!. Examples of resources include space in rackand power.

resource type intensionally defines the properties ofthe resource. Resource type is a subclass of configurationtype. We call an individual of a resource type aresourceproduction individual, since it in effect represents thefact that a resource is available or needed in a configura-tion. A resource type has acomputation definition thatspecifies whether the resource production or use must be:

• satisfied, in which case the quantity of resource pro-duced must be equal to or greater than the quantity ofthe resource used; or

• balanced, in which case the quantity of resource pro-duced must be equal to the quantity of the resource used.

The computation definition also specifies aunit of mea-sure ~Gruber, 1995!. In addition, it specifies how the pro-duction and use of the resource type by several componentindividuals are combined. This is done through atotal pro-duction function and atotal use function. The pro-totypical case is that the quantities of the resource producedor used are added together to get the total quantity. The totalproduction and use functions also define how the produc-tion or use of subtypes of the resource type are combined tothe production or use of the resource type. A subtype of aresource type may refine the attribute definitions and thecomputation definition with respect to satisfaction and bal-ancing and the total functions.

A component type specifies byproduction defini-tions anduse definitions the resource types it producesand uses. Both production and use definitions specify asetof possible resource types produced or used, aprop-erty definition, amagnitude range ~Gruber, 1995!, anda context definition. The produced or used resource must beof one of the possible resource types. The property defini-tion is a special case of constraints~see section 4.8! thatspecifies a restriction on the attribute values of the resourceproduced or used. The magnitude range specifies how muchof the resource type can be produced or used in the units ofmeasure associated with the resource type. The context def-inition specifies a restriction on “where” in the configura-tion the resource is or should be available for use. A subtype

of a component type may refine the possible types of theresource, the property definition, the magnitude range, orthe context definition.

The motivation for introducing the context in which a re-source is available is that unrestricted flow of resources fromproducers to users may model a product inadequately. A re-source is only available to component individuals that arein the same context as the producing component individual.The total production of some resource type in the configu-ration may be enough to satisfy the use but the productionmay be divided between contexts in such a manner that notall users are satisfied.

Example. In our example there are two resource types:module slots and display power~Figure 3b!. Both are re-quired to be satisfied and their production and use functionsare defined simply as sums of the resource production~Fig-ure 4 under “Resources”!. The unit of measure for them arePieces and Watts, respectively. There are no property defi-nitions for resources in this example, so we omit them.

A base-unit has three module slots which are available toAll. We define All as a special component type set contextconsisting of all component types in the configuration model.A module uses either one or two module slots in the contextall. Subtypes of module refine this amount of slots used toone or two~M-RS!. These definitions, together with the con-straintc2 ~Figure 4 under “Taxonomy”! stating that theremust be at most one HD-Module individual in a configura-tion, mean that one cannot fit the modules M-NM andM-AHD together with the M-RS-module into the base-unit.

Note that we assume here implicitly that there can existat most one Hmonitor individual in a configuration. Other-wise, a module could get the module slots from a differentmonitor individual than the one of which the module is apart. To prevent that from happening, one should define atransitive mereological context consisting of the monitor andits parts for the module-slot resource production.

A base-unit and an XGA-adapter produces 170 W and200 W of display power in the primary display and second-ary display contexts, respectively. The primary display con-text and secondary display contexts are defined as theimmediate topological context defined by the base-unit in-dividual and XGA-adapter, respectively, and the compo-nent individuals immediately connected to them. The 10-,14-, and 21-inch displays use 60 W, 100 W and 150 W ofdisplay power in the context All, respectively. These defi-nitions mean that it is not possible to have a configurationwhere there are two 14-inch displays connected to the base-unit.

Similarly as for module slots, the context of productionfor display power should have to be defined as the intersec-tion of the mereological context specified above and the to-pological contexts specified here to correctly model aconfiguration with several monitor individuals. n

Aresource is produced by component individuals and usedby component individuals in some quantities. This is con-


ceptualized asproduces- anduses-relations between com-ponent individuals, resource production individuals, andmagnitudes.A resource production individual in a produces-or uses-relation to a component individual must respect theproduction or uses definitions of the component type of thecomponent individual, that is, the resource production indi-vidual must be of one of the possible resource types and themagnitude must be in the magnitude range. Every valid com-ponent individual that produces or uses a resource must bein the produces- and uses-relations to at least one resourceproduction individual, or possibly several of them, and quan-tities specified by its component type. A valid resource pro-duction individual must not exist in a correct configurationwithout being in a produces- and uses-relations to some com-ponent individuals.

The effect of context specifications must be taken intoaccount when deciding whether resource production and useare satisfied or balanced. If both the producing componenttype and using component type of the resource type definecontexts, then the corresponding individuals must be in theintersection of the contexts for the using component indi-vidual to be able to use the resource produced by the pro-ducing component individual.

Context definitions together with the possibility of a re-source using component individual getting its resource fromseveral producing component individuals~or the other wayround! makes it necessary toallocatethe shares of the mag-nitude of the resource produced to the using component in-dividuals. For brevity, we do not discuss allocation in detailin this paper.

4.7. Functions

In this section, we consider a configurable product from thepoint of view of the functions that the product instance pro-vides to the customer, the user of the product, or the envi-ronment in which the product instance will be situated. Wemotivate the need for distinct concepts for representing func-tionality and introduce the concepts of a function type and afunction individual. We define the part definition for func-tion types that decompose functions to their subfunctions.Finally, we define how functions are mapped to the techni-cal description of the product and how the functions mayhave dependencies on each other. The concepts introducedso far are referred to astechnical conceptssince they haverisen from the technical point of view on the product.

A complex product is often configured in two stages~Tiihonen et al., 1996!. In sales configuration, the productmay be specified in terms of functions. Inengineering con-figuration, the resulting functional specification is used asan input that is refined to a technical description of the sys-tem. Engineering configuration operates within the domainof the technical concepts and on the knowledge on whichcombinations of technical concepts realize the functions inthe functional specification.

A functional specification may, for example, specify thata telecommunication switch must provide access to at least1000 subscribers. The function is mapped to a combinationof component individuals in certain relations to each otherthat realizes the function. A function cannot be easily rep-resented by any of the concepts introduced above nor can itbe considered the property of any one configuration spe-cific class. A function is not considered a resource, sinceresources in our ontology are intended to model the techni-cal rules that the product must obey. In addition, a functionmight not be produced by a set of component individuals asa resource is but by several component individuals in givenrelations to each other.

The basic concept in the functional view isfunctiontype. It is a subclass of configuration type. A function typeis an abstract characterization of the product that a cus-tomer or sales person would utilize to describe the productsuses. We call a function individual afunction. A part def-inition of function type corresponds to a part definition ofa component type with the exception that the possible parttypes must be function types.

The relation between technical concepts and functions andtheir properties is expressed asimplementation con-straints. They are a special form of general constraints~seeSection 4.8!. Several different combinations of technical con-cepts may realize the same functions and one combinationof technical concepts may realize several functions.

There can be constraints on how different functions andtheir attribute values can be combined. Thesespecifica-tion constraints are a special case of the generic con-straints ~see Section 4.8! that only refer to functionalconcepts. They are used similarly as other constraints torestrict the combinations of functions that a product canimplement.

Example. The main function of the product is to moni-tor environment~Hmonitoring in Figure 3c!. This is decom-posed to subfunctions of displaying the results of themeasurements and the optional functions of measuring gasesand liquids~Figure 4 under “Functions”!. The result dis-playing function is necessary and can be standard or high-resolution. Note that this functional decomposition does notinclude all the functional aspects of the product, for exam-ple, the modules M-NM and M-AHD cannot be specifiedby functions. In this example, it is not possible to specifyan incorrect combination of functions. If that were not thecase, specification constraints could be used to restrictthe combinations of functions to feasible ones or one couldrely on the technical definitions to rule out impossibleconfigurations.

The constraintsc5 to c8specify the implementation con-straints in our example. These specify what the technicalpart of the configuration must be like in order for the func-tions to be present in the configuration. Note that one mod-ule can implement several functions and one function canbe implemented by several alternative modules. The func-


tions high-resolution and standard display are implementedby a combination of an XGA-display-card and a 21-inchdisplay and a base-unit and a 10-inch or 14-inch display,respectively.

Note that the implementation constraints do not functioncorrectly if there were more than one monitor individual ina configuration. In such a case, the implementation con-straints would have to additionally specify that the compo-nent individuals that implement the functions must betransitively parts of the same monitor individual. n

4.8. Constraints

In this section, we define at an abstract level a general mech-anism, constraints, for specifying the interdependencies ofthe individuals and their relations. We then define a mech-anism for dividing a set of constraints to subsets that spec-ify the product from different points of view. Examplesof constraints have appeared in the examples in previoussections.

A constraint is a formal rule, logical or mathematical, ora mixture of these, which specifies a condition that musthold in a correct configuration. Constraints are a modellingmechanism that can be used when the other concepts in ourontology are not suitable for capturing knowledge on someaspect of a product. A constraint may specify arbitrarily com-plex interactions between types, individuals of types, andtheir properties using the terminology of the concepts. Weassume the existence of aconstraint languagewith enoughexpressive power to express the desired concepts. The onlyrestriction we set on a constraint language is that it must bepossible to evaluate whether a constraint is satisfied, vio-lated or its truth value is unknown with respect to a givenconfiguration.

We view a constraint as aconstraint instance whichhas aconstraint expression. We refer to constraint in-stead of constraint instance for brevity. Special cases of con-straints, has-part inheritance definitions, property definitionsof resource types, connection constraints, specification con-straints, and implementation constraints, have already beenmentioned.Aconstraint language should provide special sup-port for specifying these types of constraints.

It is often necessary to define subsets of constraints,calledconstraint sets, that limit the allowed configura-tions from specific points of view on the product. A con-straint is member of at least one constraint set. Aconfiguration satisfies a constraint set if and only if all theconstraints in the constraint set are satisfied. Correctnessof a configuration can be checked from a given point of viewby checking whether the corresponding constraint set issatisfied.

Technical and marketing constraints are examples of con-straint sets. The technical constraints limit the configura-tions on the basis of which combinations are technicallyfeasible. Marketing constraints limit the combinations onthe basis of product policy, that is, which of the technically

feasible combinations a company is willing to sell. Techni-cal constraints may be further divided into, for example,technology and manufacturing constraints.

5. DISCUSSION AND COMPARISONWITH PREVIOUS WORK

5.1. General

The ontology presented synthesizes the conceptualizationsof the connection-, resource-, product structure-, andfunction-based approaches. From the connection-based ap-proach, we have included the concepts component, port, andconnection constraint. The resource-based approach ispresent in our ontology through the concept of resource thatcomponents produce and use. From the product structure-based approach, we have included the concept of composi-tional structure that is represented through part definitionsof components and constraints on the possible parts of thecomponents. The functional approach is included in the con-cept of a function that is implemented by components.

Our ontology is by no means the first to synthesize someof these conceptualizations. However, none of the previousapproaches has combined all the concepts. We are not awareof any conceptualization or system that would allow di-rectly modelling the example product. In the conceptuali-zation by Mittal and Frayman~1989!, the connection-oriented concepts are accompanied by a limited form ofinteractions called functions. Clarke~1989! and Pernler andLeitgeb~1996! have presented approaches that extended thefunction-based approach and combined it with the structure-based approach. A set of modelling primitives combiningsome aspects of the connection and product structure ap-proaches was presented in the configuration design ontol-ogy ~Gruber & Olsen, 1996!. An independent approachcombining product structures and connections was pre-sented byAxling and Haridi~1994!.An approach which com-bined to some extent connections, resources, and structurewas presented by Stumptner et al.~1994!. Kramer~1991!presented a combination of structure- and resource-basedconcepts.

Some concepts in our ontology overlap in the sense offormal expressiveness. The constraint concept alone wouldbe enough for representing the knowledge captured by theother concepts. In our view, an ontology of product knowl-edge cannot be solely judged by its expressive power in theformal sense. A configurator may in principle represent theconfiguration knowledge using any expressive enough lan-guage such as constraints, first-order logic, or even Turingmachines. However, higher level concepts for representingtypical forms of configuration knowledge will result in amore compact and understandable representation of a con-figuration model. An ontology should also reflect the wayproduct experts such as product developers or sales manag-ers view a product. This facilitates maintaining the knowl-edge, which is a crucial issue for a configurator. Of course,


the expressive power of an ontology should be adequate tocapture the necessary knowledge.

There can exist mappings between the different conceptsin our ontology or other conceptualizations that wouldallow mapping a configuration model represented usingone subset of concepts to another representation using an-other subset of concepts while preserving the set of correctconfigurations. Although the possible mappings betweendifferent conceptualizations or different parts of our con-ceptualization are interesting, they are less important thanthe clarity of the configuration models built on the concep-tualization.

Many configuration concepts can be modeled using otherconcepts appropriately~Stumptner et al., 1994; Gruber &Olsen, 1996; Heinrich & Jüngst, 1996!. We believe that theconfiguration domain typical pieces of knowledge shouldbe modeled with a specialized construct conceptualized justfor that purpose. This makes the modelling process easierand explicates the reason for a particular interaction be-tween the components in a product. If a concept is modeledusing another concept, the origin and meaning of it may belost. The models may also become more complex.

5.2. Integration

The main concepts in our ontology, component, resource,port, and function are integrated loosely and as such theypreserve most of their meaning in the previous approaches.Unlike in many previous approaches, the main concepts aretreated uniformly with respect to several criteria. The mainconcepts are all defined both as types and individuals to ex-plicitly separate configuration model and configuration so-lution knowledge. The main concept types can all beorganized in classification taxonomies and have attribute def-initions. They can be specified as abstract or concrete todistinguish between accurate and inaccurate information.

Organizing the different concepts in a taxonomy to ex-plicitly represent their common properties and to reduce themaintenance effort is a general idea in configuration design~e.g., Cunis et al., 1989; Searls & Norton, 1990; Heinrich &Jüngst, 1991!. The explicit distinction between abstract andconcrete component types has been made by others~Kram-er, 1991; Axling & Haridi, 1994; Gruber & Olsen, 1996!,but only Weida~1996! considered it a more generic mech-anism which applies to other concepts as well. We have fol-lowed this approach. Together with refinement of properties,this provides a powerful mechanism for representing para-metric components and hierarchical partial choice~Kramer,1991!.

One aspect of integrating concepts arising from the dif-ferent approaches is to consider whether the componenttypes, resource type, port types, and function types are dis-joint concepts, that is, whether there are component re-sources, component ports, and so on. We omit these typesof entities from our ontology because we want to modular-ize the ontology with respect to the intended use of the con-

cepts by using only one concept for modelling one type ofphenomenon. The situations where a component can alsobe considered a resource can be modeled as a componenttype producing a corresponding resource type. Other com-bination concepts can be modeled similarly.

5.3. Structure

In general, the earlier work on structure in configurationhas only considered direct has-part-relation and has not ex-plicitly considered all the semantic restrictions that repre-senting a has-part-relation properly requires~Artale et al.,1996!. Our view of a compound component individual isdifferent from that of the notion of “whole” in classical mere-ology ~Artale et al., 1996! in that a compound componentindividual is an explicitly modeled entity with its own prop-erties. We do not want to impose the requirement of classi-cal mereology that all parts of a compound component typemust be modeled to account for the properties of the com-pound component type arising from the interactions be-tween its parts. This divergence from classical mereologyimplies that shared parts need not fulfill theimmediate in-ferior condition~Artale et al., 1996! required for represent-ing immediate parts properly. The condition in essence statesthat a component individual must not be part of another com-ponent individual both directly and indirectly. Exclusive partsfulfill this condition by definition.

The structure of the product can be specified in a moreflexible manner in our ontology than in the previous ap-proaches. The previous work has usually included a mech-anism to specify alternative types for parts, possibly throughsubtyping, and the number of parts~Cunis et al., 1989; Searls& Norton, 1990; Peltonen et al., 1994; Axling & Haridi,1994!. Possibility to specify a part name to distinguish be-tween parts of the same component type has been rarer~Searls & Norton, 1990; Peltonen et al., 1994!. The depen-dencies and sharing between the whole and its parts havebeen either implicitly fixed one way or neglected. The has-part inheritance mechanism between the properties of wholesand the properties of parts and transitivity of has-part-relation as explicit modelling concepts have to our knowl-edge been neglected with a few exceptions~e.g., Sattler,1996!.

5.4. Resources

Our conceptualization of resource interactions is an exten-sion of the model presented by Heinrich and Jüngst~1991!in the following respects. The produced resource types canbe abstracted and resource production and use allow varia-tion in the types and amounts produced. The shared and ex-clusive use of resource is generalizedvia the use of contexts.Context also provides a natural integration of the resource-oriented modelling to structure-oriented and connection-oriented modelling. The combination of the different


approaches through contexts seems a very powerful exten-sion of the resource oriented modelling.

As resources have attributes, it is possible to specify char-acteristics, such as quality of the resource type that is pro-duced or used. In addition to resource balancing by addingthe quantities together, we also allow resource satisfactionand arbitrary functions on how the different amounts areadded together.

5.5. Connections

The connection-oriented concepts are basically the same aspresented by Mittal and Frayman~1989!. As a generaliza-tion, we allow parameterizing component types with re-spect to the port types and number of port individuals.Integrating the port concept to the structure-oriented con-cepts, alluded to by Mittal and Frayman~1989!, is explic-itly dealt with.

The interactions between the structural concepts and con-nection concepts could be made more limited by requiringthat all component individuals that are parts of one compo-nent individual should be connected. We do not, however,require this since it would force the modeler to model allthe connections, some of which may be of no interest fromthe configuration point of view. Similarly, the connectionscould be restricted to the component individuals that are di-rect or transitive parts of the same component individual asis done by Gruber and Olsen~1996!. We do not want toenforce this modelling restriction either.

5.6. Functions

It has been argued that there is no clear distinction betweencomponents and functions~e.g., Gruber & Olsen, 1996; Wiel-inga & Schreiber, 1997!. We argue that there is a need tokeep these two concepts separate, as the sales persons andcustomers can be more interested in functions than the tech-nical structure of the product. Modeling the product throughtechnical concepts does not answer this need of describingand understanding a product through its functions. Func-tion modelling cannot take into account everything that acustomer might require but some set of functions is usuallyidentifiable. Most of the research on configuration designhas not explicitly modeled the functional domain in the sensethat we present it. The conceptualization of the functionalknowledge in our ontology is similar to those presented byClarke~1989! and Pernler and Leitgeb~1996!.

5.7. Constraints

Constraints have been used in almost all of the work on prod-uct configuration to represent the dependencies betweencomponents. Our conceptualization of a constraint as an ob-ject and an expression is similar to that presented by Gruberand Olsen~1996!. However, we do not commit to a partic-ular language or particular forms of constraints for repre-

senting them. The generality of the language is necessary tocapture the complex interdependencies between the entitiesthat occur in products. Of course, as much of the productknowledge as possible should be modeled using other con-cepts than constraints, but there are often complex inter-actions in products that cannot be captured by the otherconcepts.

Introducing constraint sets for representing different pointsof view on valid configuration is to our knowledge an ex-tension to previous work. It has its roots in our observationson how configurable products are managed by companies.The need for supporting different points of view stems fromthe different types of sales, engineering, etc. processes withina company each having different ideas of what constitutes avalid configuration.

6. CONCLUSIONS AND FUTURE WORK

The ontology presented in this paper covers the connection-,resource-, structure-, and function-oriented approaches. Itis the most generic ontology in this sense that the authorsknow of and extends the previous conceptualizations in sev-eral ways. We have tried to make minimal ontological com-mitments when specifying the concepts originating fromdifferent approaches and their interactions. Instead of com-mitting to a particular form of interaction, we have pro-vided flexibility by allowing explicit specification of theinteractions.

Our ontology does not have a minimal number of con-cepts in the formal sense for representing configurationknowledge. We do not consider this a problem. The clarityof configuration models should not be compromised by min-imizing the number of concepts in a modelling language.We believe to have struck a good balance between minimiz-ing the number of concepts and making configuration mod-els understandable.

The ontology presented should be extended and refinedto adequately cover all configuration knowledge. A generalontology should include geometric, pricing, and optimality-related knowledge and the knowledge on how to configurea product. Such an ontology should be validated by empir-ically modelling different kinds of products on the basis ofits concepts. We intend to proceed in this direction in thefuture. The relevance of the ontology depends mostly onhow easy it is to model different kinds of products.

The ontology should also be formalized into a formal on-tology to make the underlying assumptions and restrictionsclearer. This would facilitate a rigorous analysis of the on-tology and the different types of languages that can be basedon this ontology. An interesting topic would be the studyof the complexity of the inference mechanisms for suchlanguages.

It would be interesting to study whether the concepts andtheir interactions could be further refined and restricted tomore powerful modelling mechanisms. An interesting sub-ject for further research would be to investigate hierarchi-


cal refinement along has-part-relation facilitated by the has-part inheritance. The interaction between resources and portsthrough contexts could be generalized to a more bond graph-like modelling as is done by Snavely and Papalambros~1993!. This would necessitate modelling the flow of re-sources through port individuals and component individu-als at a more detailed level. The use of contexts could beextended to allow modelling various context dependent con-structs, such as constraints that hold in a given context only.

ACKNOWLEDGMENTS

We gratefully acknowledge the financial support of TechnologyDevelopment Centre Finland and Helsinki Graduate School of Com-puter Science and Engineering~HeCSE!. We thank Hannu Pel-tonen for his comments on how to improve the presentation of thepaper and for the comments on the concepts presented in this pa-per. We thank Asko Martio for the comments on the concepts pre-sented in this paper. We also thank the anonymous reviewers fortheir suggestions that certainly improved this paper.

REFERENCES

Artale, A., Franconi, E., Guarino, N., & Pazzi, L.~1996!. Part-whole re-lations in object-centered systems: An overview.Data and KnowledgeEngineering 20, 347–383.

Axling, T., & Haridi, S. ~1994!. A tool for developing interactive config-uration applications.Journal of Logic Programming 19, 658–679.

Balkany, A., Birmingham, W., & Tommelein, I.~1993!. An analysis of sev-eral configuration design systems.Artificial Intelligence in Engineer-ing Design, Analysis and Manufacturing 7(1), 1–17.

Clarke, B.R.~1989!. Knowledge-based configuration of industrial auto-mation systems.International Journal of Computer Integrated Manu-facturing 2(6), 346–355.

Cunis, R., Günter, A., Syska, I., Peters, H., & Bode, H.~1989!.PLAKON—An approach to domain-independent construction.Proc.Second Int. Conf. on Industrial and Engineering Applications of AIand Expert Systems IEA0AIE–89, 866–74.

Fowler, M. ~1997!. UML Distilled: Applying the Standard Object Model-ing Language. Addison-Wesley, Reading, MA.

Gruber, T.~1992!. Ontolingua: A mechanism to support portable ontolo-gies. Technical Report KSL 91-66, Stanford University, KnowledgeSystems Laboratory. Version 3.0.

Gruber, T.~1995!. Toward principles for the design of ontologies used forknowledge sharing.International Journal of Human-Computer Stud-ies 43, 907–928.

Gruber, T., & Olsen, G.~1996!. The configuration design ontologies andthe VT elevator domain theory.International Journal of Human-Computer Studies 44, 569–598.

Heinrich, M., & Jüngst, E.~1991!. A resource-based paradigm for the con-figuring of technical systems from modular components.Proc. Sev-enth IEEE Conf. on Artificial Intelligence Applications, 257–64.

Heinrich, M., & Jüngst, E.~1996!. The resource-based paradigm: Config-uring technical systems from modular components. InConfiguration—Papers from the 1996 AAAI Fall Symposium, ~Faltings, B. and Freuder,E., Eds.!, pp. 111–118. AAAI Press. Technical Report FS-96-03.

Kramer, B.~1991!. Knowledge-based configuration of computer systemsusing hierarchical partial choice.Proc. of the 1991 IEEE Int. Conf. onTools for AI, 368–375.

Mittal, S., & Frayman, F.~1989!. Towards a generic model of configura-tion tasks.Proc. Eleventh Int. Joint Conf. on AI, 1395–1401.

Mittal, S., & Falkenheiner, B.~1990!. Dynamic constraint satisfaction prob-lems.Proc. of AAAI-90 the Eighth National Conf. on Artificial Intel-ligence, 25–32.

Najman, O., & Stein, B.~1992!. A theoretical framework for configura-tions. In Proceedings of Industrial and Engineering Applications of

Artificial Intelligence and Expert Systems: 5th International Confer-ence, IEA0AIE-92~Belli, F., and Radermacher, F.J., Eds.!, pp. 441–50.

Peltonen, H., Männistö, T., Alho, K., & Sulonen, R.~1994!. Productconfigurations—An application for prototype object approach. InObject-oriented programming: 8th European Conference, ECOOP ’94~Tokoro, M. and Pareschi, R., Eds.!, pp. 513–537. Springer-Verlag,Berlin, Germany.

Peltonen, H., Männistö, T., Soininen, T., Tiihonen, J., Martio, A., & Su-lonen, R.~1998!. Concepts for modelling configurable products. InPro-ceedings of European Conference Product Data Technology Days 1998,pp. 189–196. Quality Marketing Services, Sandhurst, UK.

Pernler, S., & Leitgeb, M.~1996!. Functional and structural reasoning inconfiguration tasks. InConfiguration—Papers from the 1996 AAAI FallSymposium, ~Faltings, B. and Freuder, E., Eds.!, pp. 111–118. AAAIPress. Technical Report FS-96-03.

Sattler, U.~1996!. Knowledge representation in process engineering.Work-ing Notes of WRKP-96, Workshop on Knowledge Representation forConfiguration Systems. DFKI-Document D-96-04.

Searls, D., & Norton, L.~1990!. Logic-based configuration with a seman-tic network.Journal of Logic Programming 8, 53–73.

Snavely, G.L., & Papalambros, P.Y.~1993!. Abstraction as a configurationdesign methodology.Advances in Design Automation 1, 1993.

Stumptner, M., Haselböck, A., & Friedrich, G.~1994!. COCOS—A toolfor constraint-based, dynamic configuration.Proc. Tenth Conf. on Ar-tificial Intelligence for Applications, 373–380.

Tiihonen, J.~1994!. Computer-assisted elevator configuration. Master’s The-sis. Helsinki University of Technology, Helsinki, Finland.

Tiihonen, J., Soininen, T., Männistö, T., & Sulonen, R.~1996!. State of thepractice in product configuration—A survey of 10 cases in the Finnishindustry. InKnowledge Intensive CAD, First Edition, Tomiyama, T.,Mäntylä,M.,andFinger,S.,Eds.!,pp.95–114.Chapman&Hall,London.

Weida, R. ~1996!. Closed terminologies in description logics. InConfiguration—Papers from the 1996 AAAI Fall Symposium, ~Falt-ings, B. and Freuder, E., Eds.!, pp. 111–118. AAAI Press. TechnicalReport FS-96-03.

Wielinga, B., & Schreiber, G.~1997!. Configuration-design problem solv-ing. IEEE ExpertMarch–April, 49–56.

Timo Soininen is a researcher in the Product Data Manage-ment Group~PDMG! at the TAI Research Centre of Hel-sinki University of Technology~HUT! and a graduate studentat HeCSE. His main interests in product configuration arehigh-level, logic-based representation of configurationknowledge and analysis of computational properties of re-lated reasoning tasks. He has participated in a state-of-the-practice survey of 10 cases on product configuration in theFinnish industry and development of a framework for struc-tured analysis of configuration tasks and processes in a man-ufacturing company. He currently participates in nationalresearch projects on Product Data Management~PDM!which is a joint project of HUT and six industrial partnersand Design for Configurability~DFC! which is a joint projectof HUT, Tampere University of Technology and four indus-trial partners.

Juha Tiihonen also works in PDMG as a researcher. Hismain interest is product configuration, particularly methodsand tools that would enable product experts to build andmaintain product configuration models without a program-ming background. He is currently finishing his Licentiate’sthesis on the state-of-the-practice survey in the Finnish in-dustry. He is the principal developer of the framework forproduct configuration. He currently participates in the na-tional research projects on PDM and DFC.


Tomi Männistö is a researcher in PDMG and graduate stu-dent at HeCSE. His main interests lie in the data modellingof configurable products. He is especially interested in themodelling and management of the evolution of both prod-uct descriptions and product instances. He currently partici-pates in the national research projects on PDM and DFC.

Reijo Sulonenis a professor of Information Processing Sci-ence at HUT. His research interests include data base sys-tems, product data management, process modelling, softwareengineering, and electronic media.


Towards a general ontology of configuration

Documents

Transcript of Towards a general ontology of configuration