1

TOWARDS KNOWLEDGE-BASED MASS CUSTOMIZATION:

A FRAMEWORK FOR ON DEMAND DESIGN (ODD)

Alexander Tsigkas, Agis Papantoniou and Vassili Loumos

Author contacts:

Dr. Alexander Tsigkas Managing Director and Senior Consultant FlexCom AT&P Ltd. Ippokrinis 8-10 GR - 157 73 Zographou, Athens +30 210 9815731 flexcom@hellasnet.gr www.flexcom.net

Dr. Agis Papantoniou Information Technology Director Cosmoline S.A Agiou Constantinou 47 GR – 151 24 Marousi, Athens +30 210 8126150 papantoniou@cosmoline.com www.cosmoline.com Vassili Loumos Professor, Department of Electrical and Computer Engineering National Technical University of Athens (NTUA) Iroon Politechniou 9 GR 157 73 Zographou, Athens +30 210 7722537 loumos@cs.ntua.gr www.ntua.gr Abstract: The objective of this paper is to define a knowledge-based design framework for developing an interactive capability of instantaneously converting newly gained knowledge into value adding on demand products and services by and for individual persons. This approach is named: On Demand Design (ODD). ȅn demand products are configured from building blocks or components that are available on the web. The design of such building blocks or components should follow generally accepted agile design principles (GAADP). Mass Customisation target is the transformation of knowledge into "new" products or services, thus customising and adapting first knowledge then the product itself. Customising knowledge happens through instantiation and adaptation of design prototypes of the building block or the component to fit the individual needs of the customer. The on demand design (ODD) takes place in two levels: the level within which the end-designer operates in order to configure the on demand product or service from retrieved components and the level within which the component designer operates for the design of the building block or component. The ODD is open to anyone that wishes to try a design of a product or service, either with an immediate commercial, meta-commercial or research goal. Knowledge customisation for the "masses".

2nd  Intersciplinary  World  Congress  on  Mass  customization  and  Personalization,  October  6-­8,  2003,  Munich,  Germany

                                                                       http://smartcustomization.mit.edu/images/MCPC%202003/index.html

2

1. Introduction

Mass Customisation should liberate itself from the obvious opposite of Mass Production and become mature and independent (Tsigkas et al. 2003). Mass Production is based upon ‘old‘knowledge gained in the past that repeats itself through the use of it in ‘old‘products and services. But competitive advantage is not any more gained through the repeatable use or exploitation of ‘old‘ knowledge (Dixon 2000, Krogh 2000 and Daveport 1997). On the contrary we believe, that competitive advantage is gained through the creation and immediate exploitation of ‘new‘ knowledge, or "old" knowledge in producing new added value products or services. New products and services are developed and sold and can be one-of-a-kind based upon customer individual and personalised demand. The ODD is open to anyone that wishes to try a design of a product or service, either with an immediate commercial, meta-commercial or research goal.

The question is therefore how to develop a capability of instantaneously transferring and converting the newly created knowledge into value added personalised products and services for individual people and not simply for individual markets any more.

Mass Customisation in our opinion should target simply at the mass transformation of ‘new‘ knowledge or the exploitation of "old" knowledge into new individual products or services, thus customising first knowledge then the product itself. In order to achieve this we take the approach that this knowledge should be made public and offered to the world user community. Such a medium is the web. The speed with which knowledge can be converted into new personalised value-added products or services will provide in the future the competitive advantage. In our opinion this will be best achieved through the co-operation of experts forming value-added networks. These types of enterprises will be leaders in the future meta-markets that will be formed, as networks of value-added communities (VAC), a term first coined by Grady Means and David Schneider (2000), will emerge on an ad-hoc basis in order to offer personalised products and services. We call this virtual enterprise an ‘Entropy Enterprise‘. This enterprise sees its competitive advantage in the quick adaptation not only in new business environments directed from external market conditions but mainly in changes that alone are introduced into the market place in order to create new differentiation factors and capabilities for continuous wealth creation.

In this paper we begin with the introduction of our approach and why it constitutes a novice methodology in Mass Customisation (MC) that can be called e-MC. We continue with a description of how design prototypes are used to provide a framework that supports an on demand design (ODD). Then, we propose a way of how design prototypes can be formalised and structured within a Knowledge Base. Finally, in the fourth section we present our future work on the subject of ODD as a series of future articles and implementations of the ideas described throughout the current paper.

2. The On Demand Design

Mass customisation has been seen so far in the industry and the research community, as the capability of one company to offer customised and personalised products and services at the cost of mass production, upon customer demand. It basically argues that any customer would be able to design its own product. The best media for customer-based design has been seen the web. Through the Internet, users-designers will use company-owned software in order to "design" and order their product or service. These products or services follow company-defined rules the most typical of all

3

are known to be referred as Configuration Design, or Design for Variety. Although very versatile for the achievement of mass customised products these rules are: 1. not standardised and therefore not generally accepted in the business community

for similar industries and 2. products and services so designed exhibit often limited or company defined

flexibility in modifications, depending upon the chosen architecture Therefore design for MC is limited and bounded to the borders of the specific company. Basically every company establishes and follows its own proprietary standards and rules for designing product architectures and manufacturing processes. This fact limits the possibilities of the market for wealth creation, because added value is limited through the formal obstacles of knowledge structure and flow, limiting also the speed with which mass customisation can expand in the world market, creating even more wealth (Tsigkas et al. 2003). A different approach is presented in this paper. It is believed that there is much to be gained from standardising the way product and services architectures are defined. If there is wealth to be created, this will be created in the new economy, through the speed of satisfying individual needs by putting the product or service together, from components that are owned by different companies. It is quite natural that the final product or service will be "configured" by components or ingredients that may have multiple sources. Today this is reality to some extent in the PC business, due to the interconnection interface (common bus architecture), but that is about it. In order to satisfy speed requirements we need to define an agile architecture that is based on commonly accepted agile design principles. These principles should be transformed into standards, to be followed when companies design components for the MC market. The components for ODD will be designed following certain agile principles that we make the attempt here to define. We expect that these principles will further be under evolution and improvements. We would welcome any effort from the MC community to embrace these principles and to bring them to a level that we could talk about design standards for MC design. These principles are influenced from the software development for the design of objects, the broadly known concept of Object Oriented Design. On Demand products will be configured from components that are available for sale on the world-wide-web, either as a physical component or as a set of documents that are needed for local modifications and production, the so called design prototypes. The design of such components should follow generally accepted agile design principles (GAADP). Mass Customisation targets at the transformation of knowledge into "new" products or services, thus customising and adapting first knowledge then the product itself. Customising knowledge happens through instantiation and adaptation of design prototypes of the building block or the component to fit the individual needs of the customer. Although in many cases final products will be able to be "assembled" from existing components through the web, nevertheless in many cases this will not be possible, since there may be some requirements that cannot be fullfilled or the requirements are not specific enough. This we see as a rule, and in this case an adaptation or refinement of the component(s) offered will be necessary. In this case design prototypes of the component(s), instead of the instantiated component(s) will be available in order to locally modify and adapt the necessary part.

4

The configuration of the final product will take place by the customer using Internet -based configuration design software. Configuration design is a form of design where a set of pre-defined components is given and an assembly of selected components is sought that satisfies a set of requirements and obeys a set of constraints [Wielinga 1997]. According to the same author, Configuration design differs from other types of design in two respects: no new components can be designed and the set of requirements and constraints is assumed to be complete, i.e. no requirement design is necessary. Even if hierarchies of partial assemblies are used in configuration, such hierarchies are assumed to be known beforehand. Thus, configuration design is a special case of what Brown and Chandrasekaran (1989) call Class 3 design. Although this is a true statement for a product or a service that is "assembled" through existing components, the corresponding instance of the design prototype will be downloaded in order to be locally modified if the needs of the individual customer are not satisfied by the existing original component. The configuration software should be able to recognize this case and offer alternative choices. Some researchers have demonstrated that the configuration design exhibits various degrees of variations (Wielinga 1997) and have studied knowledge-based approaches in order to define Problem Solving Methods to address these various cases of the configuration design. We will have to expand their work in presenting the possibility to the user through an extended Problem Solving Method to find and select alternative choices for his needs. The On Demand Design (ODD) takes place in two levels: 1. the level within which the end-designer operates in order to configure the on

demand product or service from retrieved components and 2. the level within which the component designer operates in order to design the

component. The ODD process poses big challenges on organizations and on the structure of many enterprises, which are oriented today towards the old economies of scale, with a very high capital base. These types of enterprises will not be able to compete in the market of mass customization since they are oriented to "sell what we make" as a push concept, instead of a customer "pull", that is based on the rule "we make what is needed". Such a concept is cost intensive. The mass customization enterprise can only be a virtual enterprise that is made up of many individual companies knitted together in a network and offering special services to the final customer that he or she can be the "brand" owner. These individual specialized companies will be organized in VACs with flat hierarchies and low capital base. State of the art web technologies will play the role of the catalyst for forming the supply chain of the new products and services. Mass customisation in this respect is conveyed as a capability of nearly every individual to use the services of such a VAC, that is put together ad-hoc and on demand from the individual person. Traditional markets as we see them will be transformed into mass customized markets, where practically every person can become a designer and a "brand" owner. If traditional companies want to survive in the market of mass customized products and services they must become more flexible and leaner, so they can start outsourcing activities and organize VACs providing flexible services to these evolving meta-markets. Based on the above we expect that a meta-market will evolve from small flexible companies that will offer design services for cross-industry components that will be

5

made available on the web for the final customer to pick it and assemble his/her own final product or service.

3. Agile architecture and MC design principles

Design for Mass Customisation calls for a modular architecture. It is not our intention to establish here the rules as to how to arrive at a modular architecture, in other words as to how to arrive at decomposable products. That lies outside of the scope of this paper and it requires further research from the perspective of mass customisation. Our intention is to formulate several principles that the modules or components, of mass customisable products should be based upon. In order to do this, some background information and relevant definitions are provided as follows, adopted from the work of Ulrich and Eppinger (Product Design and Development, 2000). A product can be thought of both functional and physical terms. A product can be decomposable in functional and physical elements. The functional elements of a product are the individual operations and transformations that contribute to the overall performance of the product. For a printer for example some of the functional elements are "store paper" and "communicate with host". Functional elements are usually described in schematic form before they are reduced to specific technologies. The physical elements of a product are the parts, components and subassemblies that ultimately implement the product functions. The physical elements become more defined as development progresses. Some physical elements are dictated by the product concept. (for example, the base parts of a product family that should not change) and other become defined during the detail design phase. The physical elements of a product are typically organised into several major physical building blocks, which are called chunks. Each chunk is made up of a collection of components that implement the function of the product. Product Architecture is defined as the scheme by which the functional elements of the product are arranged into physical chunks and by which the chunks interact. Or differently said product architecture is the assignment of the functional elements of a product to physical building blocks of the product. The chunk can be compared to the object in the object-oriented design (OOD) and this is the level at which we wish to decompose a product or a service in our discussion. It has specific interfaces for interacting with other chunks, while the functionality implemented by the physical elements that belong to this chunk is encapsulated. This is the essence of Mass Customised products, since depending upon how we could cluster the elements into chunks we can facilitate to a bigger or lesser extend the customisability of the product. By adding or replacing chunks we can achieve variations in functionality of the product. OOD principles that are used in the design of SW systems can also be applied in the chunk design. These principles become the backbone for the design of MC products. Below there is a short description of those and a few examples:

6

Open Closed Principle x Design for expandability x Avoid modifications and point Solutions

Substitution Principle

x Design for reconfigurability

Dependency Inversion Principle x Design for variety x Design for expandability

Interface Segregation Principle

x Design for interface standardization

Table 1: On demand design principles The following tables describe these principles to a deeper detail level with a provision of some examples for a better illustration. Open Closed Principle for Reusability - OCP � A chunk is open for extension but closed for modifications

x chunk design should allow expansion to implement additional features

x do not modify actual chunk physical elements to implement additional functionality

� Architectural Goals of the OCP x Add new features to existing chunk, without changing the chunk and by only adding new physical elements

x Changes do not propagate into existing elements that already work

x Even partial OCP compliance can make dramatic improvements in the product Architecture.

Examples for OCP principle � Product Add-ons x many products are sold by a

manufacturer as a base unit, to which the user adds components, often produced by third parties, as needed.

x third party storage devices may be added to a basic computer

� Product Reuse x in creating a subsequent product, the firm may wish to change only a few functional elements while retaining the rest of the product intact.

x consumer electronics manufacturers may wish to update a product line by changing only the user interface and enclosure while retaining the inner workings from a previous model.

Table 2: The Open Closed Principle

7

Substitution Principle for Reconfigurability - SUP � Subclasses should be substitutable for their base classes.

x a physical element of a chunk that implements a base function can also implement a derivative of the base function

x in order to be substitutable, the contract of the base function must be honored by the derived function.

� Architectural Goals of the SUP x SUP comes in addition to OCP x minimize the physical changes

required to achieve a functional change

� Repercussions of SUP violation: x point solutions may be necessary for bridging customer needs with the existing product architecture instead of redesigning the product

x violations of SUP are latent violations of OCP

Examples of SUP principle � Product flexibility in use Some products can be configured by

the user to provide different capabilities x many cameras can be used with

different lens and flash options x some boats can be used with several

awning options x air-condition units can be delivered

with personalized grids � Product upgrades: x changing the processor board in a

computer x replace a pump in a cooling system

with a more powerful model x replace a CD-R with a CD-RW

device

Table 3: The Substitution Principle

8

Dependency Inversion Principle for Scalability – DIP � Depend on abstractions do not depend on concretions

x Dependency Inversion is the strategy of depending upon interfaces or abstract functions and classes, rather than upon concrete functions and classes.

x This principle is the enabling force behind component design

x everything concrete is volatile � Architectural Goals of the DIP x If the OCP states the goal of agile

architecture, the DIP states the primary mechanism

x No dependency should target a concrete class

x Every dependency in the design should target an interface, or an abstract class

x High level functionality is independent of the physical elements that implements them

x Interfaces are “hinge points”, they represent the places where the design can bend or be extended, without themselves being modified (OCP).

Examples of the DIP � Product Adaptation x machine tools may need to be converted

from 220V to 110V power x some long-lived products may be used in

several different environments, requiring adaptation.

x Some engines can be converted from gasoline to a propane fuel supply

� Product Wear x Physical elements of a product may deteriorate with use, necessitating replacement of the worn components to extend the useful life of the product or for safety reasons

x Tyres of a vehicle can be replaced x Various parts of an elevator system after

so many hours of use x Various parts of an aircraft after so many

hours of flight � Product Variety x a large amount of variants can be build

from a combination of standard chunks x Component Standardization x for providing the same functionality in

different products Table 4: Dependency Inversion Principle

9

Interface Segregation Principle for Portability - IPS � Many client specific interfaces are better than one general purpose (integrated) interface

x Supports components design, without it components would be much less useful and portable

x Increases level of independency of the component

� Architectural Goals of the ISP x Standardize components for portability

x Categorize interfaces according to user type

x Build user type specific interfaces for customization

Examples of ISP - Portability � Components Standardization is the use of the same component or chunk in multiple products for different user types

x Every user type may use the product differently

x this is called personalized functionality, this depends only on the interface

x an aircon with programmable user cooling or heating needs profile

x this interface can be configurable by the customer

x such components can be sold as OEM components

x an elevator cabin that can sense smart card information and gives signal to switch on lights, or the heating etc.

Table 5: Interface Segregation Principle

4. Design Prototypes

A design prototype (Gero, 1990) is a conceptual schema for representing a class of a generalized grouping of elements, derived from design cases, providing the basis for the commencement and continuation of a design. Design prototypes do this by bringing together in one schema all the knowledge appropriate for the design situation. Design prototypes form the basis upon which the design of mass customized products will be possible. Every building block or component of the mass customizable product or service will have a design prototype that accompanies it. The design principles discussed above should apply in the development of design prototypes, thus providing a knowledge representation schema separate from the specific computational processes. There seems to be a general acceptance of the classification of design into routine design, innovative design and creative design (Brown and Chandrasekaran, 1985; Coyne et al., 1987).

10

Routine design (Class 3) may be viewed as design prototype/instance refinement. Design prototypes in this case are retrieved, selected and instances are produced. These instances are refined in two ways. The first is by pruning the set of variables to the applicable set through a specification of applicable functions and/or structures and/or behaviours, propagating that specification. The second is by determining the values of the applicable set of variables using the available knowledge. Innovative design (Class 2) may be viewed as design prototype/instance refinement with an adaptation of some of the knowledge concerning applicable ranges of variable values, i.e. design prototype/instance adaptation. This requires additional processes for adaptation and then use of dependent knowledge to assist in the confirmation of the utility of any change. Creative design (Class 1) involves the introduction of new variables into a design prototype. It can be viewed as a means by which design prototypes are adapted to produce new design prototypes, i.e. design prototype generation. In most cases new prototypes are produced from old by changing them. It is possible to adapt a design prototype sufficiently so that the new design prototype is disjoint with the original prototype. On rare occasions a design prototype is generated de novo, for example, the design of the airplane, although even in this case a well-defined process could be used to explain its generation. It is expected that there will be companies specializing in the creation of new design prototypes for building cross-industrial blocks or components. Other companies may become specialized in putting together the final product from existing building blocks or components. Others will probably offer the possibility for modifications and adaptations to local requirements. The combinations in the markets are really endless, since many types of services could be developed in the two major markets of B2B and B2C. Finally, one may see even the development of a new market, C2B2C. Practically any one can define "Brand" name and sell it to the world market. Marketing opportunities, pricing and wealth creation are immense in this case.

5. A framework for On Demand Design

Designing building blocks for mass customizable products and services using design prototypes is recommended and can be thought of as matching a cognitive view of a design process model. Studies of several designers indicate that they link function and structure and select concepts to follow very early in design (Lawson, 1980). Clients in the MC era will become "mutatis-mutandis", i.e. designers themselves. We anticipate that this goal, will drive the creation and evolution of a new market, with companies or VACs that will offer the infrastructure in software and hardware as well as training for task design, especially in the case of creative design (Class 1). The final design will be then posted to the internet in order to be accepted by manufacturing companies that can bid for production. Throughout this paper, a descriptive outline of On Demand Design (ODD) using design prototypes is given. The designer commences with required functions from a client. In the Mass Customisation design process the goal is to enable the client to become the designer himself. Sometimes clients also specify required structures. These are thought of as requirements, used to retrieve from the world-wide-web, potentially useful design prototypes on the basis that they are indexed via these requirements.

11

The design prototypes retrieved represent the set of concepts that the designer 'remembers' when he or she examines the requirements. Each design prototype contains more function, structure and behavior than that which was used to index it. This is similar to being 'reminded' of additional related functions and structures. In this way design prototypes provide a means by which given a little situational information potentially appropriate concepts are retrieved and the designer is provided with a fleshed out set of concepts leading in many directions. However, not all retrieved design prototypes are likely to be equally useful and they need to be evaluated and one or more selected. Once a design prototype is selected an instance is created. Each instance represents the beginning of a design alternative. Instances are subsets of their design prototypes. They initially inherit the entire structure of the design prototype but not all of the knowledge in the design prototype may be useful in the particular context so it is pruned and thus propagated using the dependency knowledge. This process must then be part of a knowledge base that will drive the client/designer to arrive at the final choice for his/her product or service. The pruned instance is now the equivalent of a formulated design problem at that certain level of abstraction and granularity. It contains default values and normal ranges of values for variables. The various types of knowledge are used in order to determine specific values for variables. Design Prototypes are used to provide a framework that supports a design mix as stated above for the mass customizable product. This schema supports the initiation and continuation of the act of design. Design prototypes are shown to provide a suitable framework to distinguish routine, innovative and creative design. The goal of the following sections is to investigate the different types of knowledge that play a role in a MC product or service design. ODD design is proposed to require a knowledge representation framework that has sufficient expressive power to capture the nature of the concepts that support design processes. The use of a knowledge representation schema, allows for this. It separates the knowledge from the computational process that operates on it. The use of this representation effectively provides a translator between the structure of the product, and its function. We use the knowledge representation scheme that Gero (1990) has first defined, since we find it very helpful, in order to design building blocks for MC.

6. Models of On Demand Design

The purpose of design is to transform function F (where F is a set), into a design description D, in such a way that the artifact being described is capable of producing those functions. For example, when designing windows some of the functions include the provision of daylight, control of ventilation and the provision of access to a view. The design description would take the form of drawings and notes. Thus, a naive model of design is F -> D where -> is some transformation. There is, however, no direct transformation capable of achieving this result. A design description represents the artifact’s elements and their relationships and is labeled as a structure S. In the window design example the artifact’s elements are the

12

glazing, the frame and their topology. Computer-aided drafting systems have become the means by which structure is transformed into a design description, i.e. S -> D Another model of design is F ->S Here a transformation occasionally does exist in the form of a direct mapping between function and structure, often termed catalog lookup. This occurs at the element level of an artifact and is not considered as design. More generally, no direct transformation between function and structure exists. This leaves a requirement for an indirect transformation between function and structure. Function has been defined in another context as "the relation between the goal of a human user and the behavior of a system" (Bobrow, 1984). In design, behavior can be viewed in two ways. In the first place there is the behavior of the structure Bs (where Bs is a set), which is directly derivable from the structures. S -> Bs In the window design example the behaviors of the structure include the light flux transmitted, the ventilation rate, the various solar gains, etc. This process is relevant to analysis and presupposes the delineation of which behaviors need to be determined. Transforming function to expected behaviors Be (where Be is a set), provides the second view of behavior. For the window design example the expected behaviors include light transmission, ventilation rates, solar collection, etc. These expected behaviors provide the syntax by which the semantics represented by function can be achieved F -> Be This process is relevant to formulation or specification in design. The predicted behavior of the structure can be compared with the expected behavior required to determine if the structure synthesized is capable of producing the functions. Be <-> Bs where <-> is a comparison. This comparison process is similar to evaluation in design. Another model of design is F -> Be Be-> S(Bs) Here the function is transformed to expected behavior, the latter being used in the selection and combination of structure based on the knowledge of the behaviors produced by that structure. This process is relevant to that of synthesis. When structures are synthesized they produce their own behaviors which may be a useful superset of the expected behaviors. This may change the expected behaviors

13

and through them the whole function being designed for, leading to a reformulation. Reformulation can also occur when the evaluation of the comparison between the behavior of the structure and the expected behavior is unsatisfactory and cannot be made satisfactory by structure manipulation. This leads to a change in expected behavior. Above and beyond of what Gero suggests above, the expected (sensed) behavior of the product/service can change after this operation or when in use, simultaneously interacting with the person that has ordered this product or service. That may lead also to reformulation of the design that comes from the "a posteriori" learning effect that must be taken into account if the product or service should be a personalized one. In order to avoid endless reformulation loops from that reason one must be able to model the environment knowledge into the same knowledge base. The following table summarizes all transformations that take place in ODD ODD step Transformation Comments 1 Formulation

F -> Be Definition of specifications

2 Synthesis

Be -> S (Bs) Choice of structure based on its behaviour

3 Analysis

S -> Bs

4 Evaluation

Be <-> Bs

5 Reformulation

F -> Be´ -> S´(Bs´) It initiates a new synthesis

6 Production of design description

S -> D CAD drawings

Table 6: steps for ODD design

Figure 4. Model of design as a process Be = set of expected behaviours, Bs = set of actual behaviours, D = design description, F = set of functions S = structure -> = transformation, --> = occasional transformation, <-> = comparison

F

Be Bs

S D

evaluation

analysisformulation reformulation

synthesis

reformulation

14

7. Knowledge-based framework design

This section proposes the way to formalise and structure within a Knowledge Base the ODD prototypes. The purpose is to identify some of the problem solving mechanisms that apply to the development of the “right” mix of design class components or optimal product design based upon customer requirements and product design feasibility for the target cost. This Knowledge Base constitutes one of the fundamental components of a Mass Customisation Support System (MCSS) that the authors will introduce in future publications. This system is discussed to reveal similarities with an Intelligently Amplified System, according to Brooks (1996) and not a mere Artificial Intelligence system, since its main objective is to support a human user in decision making and not to decide on behalf of the human user. The structure of this Knowledge Base follows Description Logics guidelines (Naardi 2002). It involves a Terminological Box (T-Box), an Assertional Box (A-Box) and a set or rules. Due to the structure of the Knowledge Base, the MCSS is able to visualize two different views of the knowledge it contains. The first view consists of a set of rules that guide the consumer during the design process of the product according to his/her preferences. The second view consists of a Knowledge Desktop, used from the product designers of the company that develops new Flow-based design prototypes (creative design according to John Gero) that will enlarge the choice possibility of the consumer that wants to design his/her personalized product. This work of course can be conducted over the Web. For this task the significant freedom representing resources, that the Semantic Web technologies offer, leaves no doubt concerning the choice of the representational formalism. Therefore the Resource Description Framework (RDF) Schema extensions (Brickley 2000), that DARPA Agent Markup Language and Ontology Interchange Language (Horrocks 2000, van Harmelen 2001) propose will be adopted for the construction of both the terminological and assertional ontologies. The same formalism will be equally employed for the definition and declaration of the rules that will be made available to the user in order to customize the product according to his/her individual needs (design class mix). The benefits, stemming from the adoption of the above mentioned Knowledge Representation technologies, are summarized so that the formalism is simultaneously expressive and rich. In this way Mass Customization design rules can be represented as axioms and both can be built on a Knowledge Level (Newell 1982) as Maedchke (2000) and Staab (2001) propose. Based on the above it is the authors’ opinion that further exploitation of this approach will form a concrete basis for further research on the area of MCSS design and implementation.

8. Conclusions and further research

As an overall conclusion this paper tries to:

a. Clarify the issues around MC definition and provide a first relevant framework b. Investigate the differences between Mass Customization and Mass Production

product design c. Provide extensions to Flow through Design prototypes and Design classes d. Provide a Knowledge Representation scheme for Product and Process Design e. Discuss the aspect of new generation knowledge-based MC compliant CAD

systems and provide a first technical orientation on the subject Finally, as already mentioned in the beginning of the paper, the authors’ intention is to provide future work in the area of Mass Customization standardization as a series of

15

future articles and implementations of the ideas described throughout the current paper.

9. References

Bobrow, D. G.(1984). Qualitative reasoning about physical systems: an introduction. Artificial Intelligence (1984) 24(1-3):1-5

Brickley D. / Guha R.V. (2000), Resource Description Framework (RDF) Schema Specification 1.0, 27 March 2000 (W3C Candidate Recommendation).

Brooks F.P. (1996), “The Computer Scientist as Toolsmith II,” Comm. ACM, Vol. 39, No. 3, Mar. 1996, pp. 61–68

Brown, D. C. / Chandrasekaran, B. (1985): Expert systems for a class of mechanical design activity, in: J. S. Gero (ed.) Knowledge Engineering in Computer-Aided Design, Amsterdam, North-Holland, pp.259-282

Brown, D. C. / Chandrasekaran, B. (1989): Design Problem Solving: Knowledge Structures and Control Strategies. Research Notes in Artificial Intelligence, London, Pitman.

Coyne, R. D./ Rosenman, M. A. / Radford, A. D. / Gero, J. S. (1987): Innovation and creativity in knowledge-based CAD in: J. S. Gero (ed.) Expert Systems in Computer-Aided Design, Amsterdam: North-Holland, pp. 435-465.

Davenport T. / Prusak L. (1997): Working Knowledge, Boston: Harvard Business School Press 1997

Dixon, N (2000): USA 2000 Common Knowledge: How companies thrive by sharing what they know, Boston: Harvard Business School Press 2000.

Gero, J. S.(1990): Design prototypes: a knowledge representation schema for design. Artifitial Intelligence (1990) 11(4) 26–36.

Horrocks I. / Fensel D. / Broekstra J. / Decker S. / Erdmann M. / Goble M. / Van Harmelen F. / Klein M. / Staab S. / Studer S. (2000). The ontology inter-change language oil: The grease between ontologies. Technical report, 2000.

Krogh, G.V./ Ichijo, K. / Nonaka I. (2000): USA 2000,Enabling Knowledge Creation, Oxford University Press.

Lassila O. / Swick. R.R. (1999) Resource description framework (rdf) model and syntax specification. Technical Report REC-rdf-syntax-19990222, W3C, 1999.

Lawson, B. R. (1980): How Architects Think, London: Architecture Press.

Maedche A. / Schnurr H.P. / Staab S. / Studer R. (2000) Representation language-neutral modeling of ontologies. In U. Frank, editor, Proceedings of the German Workshop ”Modellierung-2000”. Koblenz, Germany, April, 5-7, 2000.Folbach-Verlag, 2000.

Means, Grady / Schneider, David (2000): MetaCapitalism, the e-Business Revolution and the design of 21st-Century Companies and Markets, John Wiley and Sons Inc.

16

Nardi D. / Baader F. / Calvanese D. / McGuiness D. / Schneider P.P. (2002) The Description Logics Hanbook : Theory, Implementation and Applications, to be published by Cambridge University Press, 2002.

Newell, A. (1982). The knowledge level, Artificial Intelligence, Vol. 18.pp 87-127

Staab S. / Maedche A. (2000) Axioms are objects, too- ontology engineering beyond the modeling of concepts and relations. Technical Report 399, Institute AIFB, Univ. of Karl-sruhe, 2000.

Tsigkas, Alexander / de Jongh Erik / Papantoniou, Agis / Loumos, Vassilis (2003): Distributed Demand Flow Customization, in: Mitchell M. Tseng, Frank T. Piller (eds.) The Customer Centric Enterprise, Springer 2003, pp. 361-378

Ulrich T. Karl / Eppinger D. Steven (2000): Product Design and Development, second edition, Irwin-McGraw Hill 2000, pp. 181-203

van Harmelen F. / Patel-Schneider P. / Horrocks I. (editors) (2001), Reference Description of the DAML+OIL ontology markup language

Wielinga, B. J./ Schreiber TH. A. (1997): Configuration design problem solving