1. INTRODUCTION
In this paper we present a conceptual and computational framework for the development of knowledge-based systems to support experts of small and handicraft enterprises involved in the design and manufacturing of high quality products for limited serial productions.
The paper investigates how functional knowledge can be profitably acquired and represented through the usage of a specific knowledge artifact (KA; Salazar-Torres et al., Reference Salazar-Torres, Colombo, Correa da Silva, Noriega and Bandini2008) composed of four conceptual tools: ontologies, SA*-Nets, T-Matrix, and Task Structures for Complex Object Design (TS-CODE). Ontologies are one of the most suitable approaches to represent functional knowledge about a domain. In our framework, ontologies are used to specify the structure of a product with respect to the functional nature of the relationships existing among its parts. SA*-Nets are useful in the specification of how the design process is represented in terms of design phases and relationships among them. The T-Matrix tool allows representing how different structural components of a product can be aggregated from the functional point of view, as well as the relationships existing between functions and the final performances the product must have to be successful. Finally, TS-CODEs allow the description of how a specific design phase is managed by expert designers according to their experience.
This framework is particularly suitable to develop supporting systems for handicraft enterprises involved in the design of innovative products, especially when such products are because of the collaboration among networks of small and medium enterprises (SMEs).
To make clearer the theoretical aspects of this approach and the benefits for networked SMEs, a case study related to the GUITAR HERO project will be presented. The project is the result of the collaboration between CSAI (www.csai.disco.unimib.it) and NOAH Guitars (www.noahguitars.com), an Italian SME leader in the production of high quality guitars. An electric guitar is a complex product in which each part has a precise function, and some of them influence others. For example, body is the main part of the guitar; different from acoustic guitars, the body of electric guitars has no significant role from the musical point of view, but it is responsible for connecting all other components.
Although electric guitar bodies are traditionally made of wood, NOAH guitar body design and manufacturing are based on the adoption of aluminum.
The aim of the GUITAR HERO project is to build a knowledge model of the decisional process of NOAH experts. To do this, we have decided to follow the methodological approach exploited in the IDS project (Bandini & Sartori, Reference Bandini and Sartori2006), with the definition of three different levels of knowledge to be acquired and represented:
1. ontological knowledge, related to the definition of structural and functional relationships (Colombo et al., Reference Colombo, Mosca, Palmonari and Sartori2007a) among guitar parts;
2. procedural knowledge (Friedland, Reference Friedland1981), related to the description of how the guitar components are manufactured, as well as which factors influence the different steps of the process; and
3. experiential knowledge, devoted to represent into a homogeneous conceptual framework the heuristic rules adopted by the different kinds of expert involved.
The paper will be organized as follows: after a brief introduction to clarify the motivations of the work, a review of literature will be provided, from both the existing ontological approaches to support design and the KA adoption. Then, the paper will describe the domain of the case study: a brief literature review about knowledge management (KM) to support SMEs and networks of SMEs, and the results of the knowledge acquisition campaign conducted with NOAH experts. Moreover, the KA introduced to give a characterization of NOAH guitars will be described.
Another section of the paper will be devoted to computational aspects of the GUITAR HERO project, to show how the KAs developed can become an effective knowledge-based system to support NOAH experts in their decision making process. In particular, this part of the paper will focus on the NavEditOW tool, an application for Navigating, Editing, and Querying Ontologies over the Web and its use in the GUITAR HERO project.
Finally, conclusions and future works will end the paper.
2. MOTIVATIONS
Knowledge-based system applications have a big potential to reduce cost and time for repetitive engineering tasks, but require a relevant effort to collect and formalize the required knowledge in an opportune scheme. In this field, generally referred to as engineering design, one of the most known examples of application to the industrial planning of complex objects has been proposed by Gero and Maher (Reference Gero and Maher1997): they defined specific knowledge representation schemes, the so-called prototypes (Gero, 1990), for describing the conceptualization and ideation process generally followed by a draftsman. In this framework, the case-based design paradigm has been suggested to reuse previous solutions to solve similar design problems (Maher et al., Reference Maher, Balanchandran and Zhang1995).
Engineering design can be considered an articulate process composed of phases, where each phase represents a combinatorial action on the parts the composite object is constituted of: to realize an object meeting the desired market requirements, designers have to deal at the same time with different kinds of knowledge coming from at least two epistemological sources: ontological knowledge (Guarino, Reference Guarino1998), which is often represented in a declarative form, and procedural knowledge, about processes of design.
Many references in the literature, like Deng (Reference Deng2002), Kitamura (Reference Kitamura, Sano, Namba and Mizoguchi2002), Bracewell and Wallace (Reference Bracewell and Wallace2001), and Umeda et al. (Reference Umeda, Ishii, Yoshioka, Shimomura and Tomiyama1996), indicate that the competence of engineering designers is related to their ability in considering functional constraints over the parts of the objects they are designing. According to our viewpoint, this expert designers' competence gives the ability to navigate ontological and procedural knowledge considering different kinds of relationships among parts of the desired object. The central role of heuristics in performing design tasks mainly resides in this capability to shift through different epistemological dimensions. We look at design heuristics as a set of competencies, growing from experience, which bridge the gap between ontological and procedural knowledge and makes designers able to articulate the design process referring to functional constraints.
Therefore, the development of knowledge-based systems supporting engineering design activities must take into account the formal representation of both these knowledge sides as described by Umeda and Tomiyama (Reference Umeda and Tomiyama1997): function plays a crucial role, because the results of the design depend entirely on the decomposition of the function and on the designer's capability to build the appropriate object realizing that function. As a result, the designer obtains a hierarchy of functions that are projected on the aggregate of parts the composite objects is constituted of.
Thus, when designers speak about the “function” held by an object or by one of its components, they can speak about it because they have sufficient knowledge for associating functions to a suitable object structure.
The nature of the functional relations, however, can widely vary. Understanding these relations allows engineers to reason about the artifacts and to make clearer the sets of ontological and procedural constraints necessary to meet market requirements. Despite many frameworks for engineering, design KMs have been developed, for example, the EDIT methodology by Ahmed et al. (Reference Ahmed, Kim and Wallace2007). Based on the adoption of functional ontologies, our approach is radically different from them, because we have adopted a KM perspective based on the integration of multiple tools: ontologies, for the description of object structure with the aim to identify functional systems, SA*-Nets, for the description of engineering design steps from the procedural point of view, and T-Matrixes and TS-CODEs for the definition of object performance on the basis of designers' experience. The composition of such tools defines our KA for engineering design.
3. CONCEPTUAL TOOLS FOR FUNCTIONAL KM: ONTOLOGIES
The first shared knowledge structure allowing the contracting activity in common problem solving can be represented using the ontology approach (Guarino, Reference Guarino1995). At a first glance, the hierarchical structural decomposition of an object to design (is-a, part-of relations) could represent the right structure of this kind of knowledge, because of the classificatory capabilities of the senior design professionals.
The mere joining of this ontological setup with knowledge involving the functionalities (not captured by is-a, part-of relations) of the involved object parts can be conceptually complicated and sometimes not feasible. A different and more suitable conceptualization has been adopted as shown in Figure 1.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215558-29295-mediumThumb-S089006040999014X_fig1g.jpg?pub-status=live)
Fig. 1. An object can be decomposed, according to three different levels of complexity, into several functional systems, aggregates, and elements.
The object to design is requested to perform different functions: each conceptual part of the product that performs a specific function is called functional system. An object can be considered as a collection of one or more functional systems. Functional systems, however, can be fairly complex. Sometimes, designers conceive them as a composition of lower level aggregates, which are semimanufactured components to be grouped together for making simpler and faster the design of a functional system. Finally, elements are (atomic) elementary parts; their role can be different according to the aggregate (and, consequently, functional system) they belong to.
4. CONCEPTUAL TOOLS FOR PROCEDURAL KNOWLEDGE: SA*-NETS
The functional ontology introduced above clearly describes the different components of the object to design and their functions. Procedural knowledge concerns the design of single parts, focusing on precedence constraints that must be taken into account to avoid possible mistakes in the design task. These constraints can be because of manufacturers' guidelines as well as geometric considerations.
To properly represent procedural knowledge we have adopted a specialization of Superposed Automata Nets (SA-Nets). This specialization is called SA*-Nets. SA-Nets (De Cindio et al., Reference De Cindio, De Michelis, Pomello and Simone1981) are formal tools for the analysis of concurrent systems. The main idea behind the adoption of such tool in the knowledge-based system context is that the design of object parts can be considered as sequences of steps, which are executed either sequentially or contemporary. During this process, it is possible that a design step is influenced by the results of another one related to a different part, generating a synchronization between two distinct components: each design step can be represented by a transition in a formalism like a Petri Net. To take care of synchronizations, opportune relationships are considered (see Fig. 2).
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215724-31068-mediumThumb-S089006040999014X_fig2g.jpg?pub-status=live)
Fig. 2. The design steps of two mechanical object parts: the dashed arrow linking design step 1 of object part 2 and design step 2 of object part 1 indicates that design step 1 must be accomplished before.
4.1. Definition 1 (SA*-Nets)
A SA*-Net is a 4-tuple 〈S, T, A, R〉 where
• S is a set of states (i.e., circles in Fig. 2);
• T is a set of transitions (i.e., rectangles in Fig. 2);
• A is a set of arcs, links between states and transitions of a SA*-Net (i.e., solid arrows in Fig. 2) or between transitions belonging to different SA*-Nets (i.e., the dashed arrow in Fig. 2); and
• R is a set of rules to describe how precedence relationships among die parts are established.
The set S contains two special states begin and end, which identify the starting and ending points of a product design. It is important to notice that states of SA*-Nets are completely different from states of Petri-Nets or SA-Nets. In fact, states in SA*-Nets allow identifying all the design steps already executed: in this sense, a marker on a state of a SA*-Net does not indicate the possibility for the outgoing transition to fire, but it does indicate that the design step above it has been already accomplished.
Transitions represent design steps and are bounded to states above and behind them by means of arcs. There exist two particular transitions, namely, fork and join, that are used to identify points where concurrency among distinct sequences of design steps begins or finishes, respectively. Arcs are not labeled and can have two semantics: they can represent a sequential flow in the execution of design step with reference to an object part or precedence constraints between two design steps that are in the same or different SA*-Nets.
Finally, rules specify how the SA*-Net is browsed and used. Rules can belong to the following three categories, as shown in Figure 3:
• Rule number 1: within a SA*-Net, given an executed transition, all the transitions above it must be already visited;
• Rule number 2: if a transition T 1 of a given SA*-Net is bounded to a transition T 2 of another SA*-Net by a precedence constraint, the transition T 2 must be already visited;
• Rule number 3: if a transition T 1 is the result of a join among transitions T 2, … , T n, transition T 1 can be executed if and only if all the transitions T 2, … , T n have been already visited.
Starting from the ontological representation of the object, a SA*-Net for every functional system identified must be produced. Such net completely describes the different design steps needed to design the functional system it refers to, by means of aggregates and elements usage and configuration. The composition of all the SA*-Nets through the fork/join transitions allows the designer to give a clear and complete description of the main object design process, following a bottom-up strategy.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215748-75610-mediumThumb-S089006040999014X_fig3g.jpg?pub-status=live)
Fig. 3. A representation of the three categories of rules adopted in the framework. [A color version of this figure can be viewed online at journals.cambridge.org/aie]
5. CONCEPTUAL TOOLS FOR EXPERIENTIAL KNOWLEDGE: T-MATRIX AND TS-CODE
Given a complete SA*-Net, Experiential Knowledge concerns how the different design steps are effectively accomplished by the designer, according to his/her own style. Each transition in the SA*-Net is then further specified by a group of specific tools, in terms of preconditions to be verified and actions to be done. Typical actions are the evaluation of geometric parameters and suggestions about an aggregate (or element) to include in the project with respect to another one. Preconditions typically concern precedence constraints among transitions or object parts.
In our framework, two kinds of tools have been considered: T-Matrix (Colombo & Sartori, Reference Colombo and Sartori2003) and TS-CODE.
T-Matrix aims at the representation of relationships among ontological elements, aggregates, functional systems, and object performances. The result is a table where it is possible to define which correlation (i.e., weak, good, strong, or none) exists between a group of elements and the functional system they belong to, together with the related proportionality (i.e., direct or inverse); then, a deeper functional analysis can be made by analyzing which kind of relationship exists between groups of functional systems (i.e., a representation of object properties from the designer point of view) and object performances (i.e., a representation of object properties from the user perspective). The result is a T-like structure similar to the one depicted in Figure 4.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215809-39519-mediumThumb-S089006040999014X_fig4g.jpg?pub-status=live)
Fig. 4. The T-Matrix representation.
Ontology elements and aggregates are listed in the matrix rows, as well as object performances. Functional systems are put on the columns.
Looking at the example in the figure it is deduced that Aggregate1, Elementn, and Aggregatel belong to Functional Systemj, because their correlations with it are strong, good, and good, respectively. This means that object functions delivered by Functional Systemj widely vary by changing Aggregate1, Elementn, and Aggregatel attributes. In particular, although an improvement of Aggregate1 and Elementn would improve Functional Systemj characteristics accordingly because of their direct proportionality value, an increment of Aggregatel features would induce a decrement on Functional Systemj, because they are inversely correlated: as a consequence, the designer could operate on Aggregate1 and/or Elementn parameters to preserve Functional Systemj functionality.
A similar interpretation is possible for the upper part of the table, concerning relationships among functional systems (i.e., functions defined by object designer) and performances defined by the object user: for example, Functional System2, Functional Systemj−1 and Functional Systemj have influence on Performancem−1, whereas Functional System1 has not.
Although T-Matrix is useful in the definition of functional relationships on ontologies according to the knowledge of experts, another conceptual tool has been thought to represent knowledge involved in design steps' specification.
This tool is Task Structure for Complex Object Design (TS-CODE), a specialization of Task Structures introduced by Chandrasekaran (Reference Chandrasekaran1989). According to its definition, a Task Structure should concern a portion of the knowledge model, giving a synthetic description of inputs, outputs, and a body describing the problem solving strategy to get outputs from inputs. In our framework, a TS-CODE is used to specify a design step involved in the definition of a functional system, as shown in Figure 5.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215826-22348-mediumThumb-S089006040999014X_fig5g.jpg?pub-status=live)
Fig. 5. TS-CODE representation.
5.1. Definition 2 (TS-CODE)
A TS-CODE is a 4-tuple 〈L, I, O, B〉 where
• L is the label of the task, that is, the name of the functional system or design step it refers to;
• I is a set of inputs, that is, values that must be used in the body to obtain expected results;
• O is the output of the task, that is, a value representing the expected result of the knowledge model part defined by the task; and
• B is the body of the task, that is, a set of instructions specifying the problem solving strategy adopted to obtain expected results from given inputs.
In case of precedence constraints between two design steps, the TS-CODE representing the influenced task will contain a call to the TS-CODE representing the other task.
Finally, a distinction between task and subtask has been made: a task is the representation of a functional system, a subtask is a representation of a part of that functional system, that is, a given design step. In other words, whereas the task body ends returning the output O of the functional system, a subtask calculates a partial value that is necessary to obtain that output. A subtask is identified in the task body as a procedure call. In this way, it is possible to give a clear and understandable structure to the knowledge model involved in the design of a functional system, reusing the code for a subtask in more than one task. As highlighted in Figure 5, subtasks' inputs are subsets of the task input set, and the task output is the result of a MERGE function that exploits the partial results elaborated by subtasks.
6. PUTTING ALL TOGETHER: KAs FOR COMPLEX OBJECT DESIGN
The three kinds of tools introduced so far can be used to build a specific KA for Design, through which uniform and integrated models of distinct types of knowledge concerning design can be developed.
The notion of artifact has many meanings in literature: for example, in Hilpinen (Reference Hilpinen and Zalta2008) we find that an artifact is an object that has been intentionally produced for a specific purpose. Moreover, according to De Michelis (Reference De Michelis1998), an artifact is the result of a disciplined human activity, following rules and based on training and experience. As a consequence, every artifact has an author and a purpose.
Artifacts can be evaluated in terms of how their actual features match the features intended by their authors and the purposes to which they are built. Given a purpose P, an author A devises an artifact and obtains an invention, an idea or a project that describes the artifact at an abstract level. We can refer to this object, resulting from the author intellectual work, using the symbol I. Finally, the actual artifact R is used for the purpose P. It should be noticed that the purpose that has produced both the design of I and the implementation of the artifact R could differ from the purpose of the user of an artifact.
The artifact R described by I is the real object. The author would like R to have the intended features to fit the original purpose P. The description I of the artifact is clearly the result of a design process. It is a formal and abstract representation of an actual object R. The devised artifact needs to be implemented, to produce the actual artifact R that is going to be used.
As presented in Figure 6, P, I, and R are related through design, implementation, and utilization. A successful set of relationships is that in which a design leads to an I that perfectly matches a given purpose P, whose implementation leads to an R that perfectly matches I, and such that the utilization of R also perfectly matches P.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20160328100453852-0862:S089006040999014X_fig6g.gif?pub-status=live)
Fig. 6. Design, implementation, and utilization of an artifact.
One interesting point to be noticed is that the arrows in Figure 6 are one-to-many relations. In fact, a purpose P can lead to a variety of designed artifacts I 1, I 2, and so forth.
Summarizing, an artifact is hence characterized by a particular triple 〈I, R, P〉, in which a design I is implemented as an actual object R that is used for a purpose P. The separate elements I, R, and P can be put together in a triple 〈I, R, P〉 that is the “artifact in the context” view of the artifact R.
Our focus is not on artifacts in general but on KAs, which are artifacts designed and implemented with the aim to represent expert knowledge in the object-manufacturing field. For this reason, a KA suitable for the framework proposed in this paper should be able to bind ontological description of the object and procedural one (as previously described) through the acquisition and representation of expert knowledge involved in this task. Thus, we can now define a KA for the design and manufacturing of complex objects as follows:
6.1. Definition 2 (KA)
A KA for the design and manufacturing of complex objects is a triple 〈P, I, R〉 where
• P is the set of functional systems that defines the object, as described by the ontology;
• I is a set of design steps to define how each functional system is projected, as described by the SA*-Net; and
• R is a set of conceptual tools to represent expert knowledge involved in the definition of functional properties of the object, like the T-Matrix, or to describe how each design step is accomplished by the object designer, like TS-CODE.
7. COMPUTATIONAL TOOLS TO MANAGE KAs: NavEditOW
Up to now, we have presented an approach for the modeling of conceptual KAs involved in design. Of course, this methodological approach should be properly mapped on a collection of suitable computational tools to build effective knowledge-based systems based on it. T-Matrix and TS-CODE can be naturally implemented by means of production rules of a rule-based systems approach. In fact, they are characterized by a set of preconditions to be verified and a set of actions to make in case of positive pattern matching on preconditions. SA*-Nets must be supported by ad hoc editors, which allow specifying the rules concerning the management of procedural knowledge. To represent ontological knowledge, we have developed a specific tool based on semantic Web technology, named NavEditOW (Bonomi et al., Reference Bonomi, Mosca, Palmonari and Vizzari2007). This part of the paper is devoted to describe the main aspects of such tool, both from the theoretical and practical standpoints.
Before developing a new system, we have analyzed the principal tools of this area. One of the most popular ontology editor is Protégé. It is a free, open-source ontology editor and knowledge-based framework. A detailed description of Protégé is out of the scope of this paper and can be found in Knublauch et al. (Reference Knublauch, Musen and Rector2004). Protégé allows editing of ontologies expressed in OWL. Protégé is one of the best OWL editors, but its user interface is too complex for a user with no experience of ontological languages and lacks some useful functions like the inspection of the elements (e.g., via hyperlinks) and comfortable edit/visualization facilities for the individuals.
NavEditOW (see Fig. 7) allows overcoming these problems exploring the concepts and their relational dependencies as well as the instances by means of hyperlinks; moreover, it provides a front end to query the repository with the SPARQLFootnote 1 query language.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20160328100453852-0862:S089006040999014X_fig7g.jpeg?pub-status=live)
Fig. 7. NavEditOW Web Interface developed for the GUITAR HERO project. [A color version of this figure can be viewed online at journals.cambridge.org/aie]
More details about NavEditOW usage will be supplied after the introduction of the framework scenario in the context of GUITAR HERO project (see Section 8).
8. FRAMEWORK SCENARIO: SUPPORTING HANDICRAFT ENTERPRISES
As briefly explained in the introduction, the framework has been thought to support experts of small and medium and handicraft enterprises in the design of their products, to help them to capitalize their knowledge, and make simpler and more efficient communication with partners and suppliers. In particular, the framework is devoted to support the building of common jargon and understanding of a product inside networks of SMEs involved in its design and manufacturing.
Many researches have been carried out in the KM context, both from the theoretical and the practical standpoint to support SMEs in their day-by-day activities and to join SME networks. From the theoretical point of view, many conceptual frameworks have been developed, starting from the well-known work by Nonaka and Takeuchi (Reference Nonaka and Takeuchi1995), who distinguish between tacit and explicit knowledge and adopt the knowledge creation spiral to represent them. This model describes a dynamic environment where tacit and explicit knowledge are continuously exchanged and transformed through socialization, combination, externalization, and internalization.
Another important contribute comes from Handzic (Reference Handzic2006), who highlights the relevance of KM for SMEs, given that typically they have no more than 50 employers. Handzic argues that although the small size of an enterprise is a benefit from the agility perspective, in contrast, it is a drawback thinking at the consequent vulnerability in terms of loss of key personnel.
This is probably the key aspect to deal with in the development of KM systems for supporting SMEs: a KM application must take into account the creation of a knowledge model helping the SME to survive in case of absence of one or more experts. This is particularly true in the case of networked SMEs, where experts are geographically distributed: the loss of communication between two members of the cluster should not generate loss of time (and consequently, money) in the whole decision-making process.
The main aim of a KM project in the networked SMEs should be the representation of knowledge to create shared models that can help each SME to keep the current state of the project under control, without delays in receiving inputs and producing outputs.
From the practical standpoint, many researchers have focused on the development of decision support systems to allow SMEs increasing their technological level in many different fields. For example, the Symphony project (Bandini et al., Reference Bandini, Mereghetti, Merino and Sartori2007) was funded by European Community to develop a KM system to support experts of human resources of SMEs in the employer selection process. In that experience, candidate profiles were compared according to a case-based reasoning approach (Kolodner, Reference Kolodner1993).
At any rate, it is still very difficult to build effective KM systems for networked SMEs, because of logistic problems in acquiring, representing, and implementing knowledge owned by experts who are not physically in the same place: typically, these systems are characterized by the fusion of different kinds of computer-based applications into an unique computational framework.
A significant experience in this sense comes from the KNOW-CONSTRUCT project (Soares et al., Reference Soares, Simoes, Silva and Madureira2006), which aims at providing SMEs of the construction sector with a sophisticated information management platform and community building tools for knowledge sharing. The KNOW-CONSTRUCT system exploits ontologies for building reusable pieces of domain knowledge to be structured and classified according to their use into specific meta models, suitable to build knowledge repositories for construction industries, called Construction Industry Knowledge.
This model contains information and knowledge about products, processes, problems, best practices, legislative issues, and so forth, and it is used by the system for exporting two kinds of functionalities: Customer Needs Management and Knowledge Community Support.
The second functionality is the more interesting from the KM perspective, because it concerns the development of technologies, methods, and tools to support knowledge sharing and maintenance over a Web-based architecture. To this aim semantic Web technologies are fundamental to provide systems with capability to retrieve complex and heterogeneous information, generated both internally and externally to the knowledge community.
In the following, we will present an approach similar to the one adopted by KNOW-CONSTRUCT developers, where functional ontologies are used to build a meta model of a complex product, namely, an electric guitar, that is the result of collaboration among a collection of SMEs located into a small Italian regional cluster. Through the use of a proper KA it has been possible to help the network to overcome problems in communication because ofthe lack of an opportune technological infrastructure. As a consequence, the development of a shared model of knowledge involved in the decision-making process has been possible. This has allowed the clear definition of roles and the implementation of ERP functionalities that are very useful to solve organizational problems.
9. FRAMEWORK APPLICATION: THE GUITAR HERO PROJECT
The guitar is a relatively recent kind of musical instrument: the first models of guitars where built by Antonio Torres Jurado in the 19th century. The guitar acquires importance in the 20th century and, in particular, in the period between 1930 and 1950, when American manufacturers like Fender and Gibson gave very important stimulus to the development of guitar acoustics.
A very important point of break is the birth of electric guitars, whose acoustic properties depend on specific electric components rather than on properties of materials and guitar morphology. These components are called pickups, and they are able to “capture the vibrations” of strings moved by the player conveying them to amplifiers.
9.1. The guitar components
An electric guitar is generally composed of the following parts (see Fig. 8). Body is the main part of the guitar, where the pickups and bridge are located. Bridge is an area of the guitar through which the strings are connected to the body. Very often, strings are placed on saddles. Saddles are configurable and can be single (i.e., each saddle is devoted to the connection and regulation of one and only one string) or double (i.e., each saddle is devoted to the connection and regulation of two strings). There exist many different kinds of bridge, some of the most used are tremolo bridges (e.g. Wilkinson or Bigsby), adjustable bridges, and fixed bridges. Frets are vertical metal wires that sit vertically on the guitar neck. Headstock is the area of the guitar at the end of the neck where the strings are fixed and tuned, and neck is the long narrow part of the guitar where notes are fretted. Located between the body and headstock of the guitar, the neck is usually a wooden part: to limit negative effects of deformations, an adjustable steel bar called a truss-rod is placed inside it. The truss-rod can be adjustable at the headstock or adjustable at the body. Nut is the point on the guitar neck where the strings touch the neck and join the headstock. The pickup switch is located on the body of the guitar used to select different pickups for different tones and sounds. The pickup is a magnet wrapped in copper wires that sits on the face of an electric guitar, underneath the strings. When the strings move, they interfere with the magnetic field of the pickup, and that impulse is sent to the amplifier. There are many kinds of pickups according to the number of coils they are made up of. Typically, single-coil (more subject to noise) or multicoil (humbuckers) (less subject to noise) pickups are adopted; tremolo (i.e., whammy bar) is a bar connected to the bridge of the guitar. By moving the tremolo bar up or down the bridge moves consequently, thus changing the pitch by loosening the tension of strings. Tuning pegs are the pegs located at the headstock, which are used to tune the guitar. The machine heads have gears that can tighten or loosen the string when turned. Volume and tone control are control knobs located on the body of the guitar and used to adjust guitar volume and tone.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626220019-31167-mediumThumb-S089006040999014X_fig8g.jpg?pub-status=live)
Fig. 8. The main components of an electric guitar. [A color version of this figure can be viewed online at journals.cambridge.org/aie]
In the next section, we will describe the object of the GUITAR HERO project, that is, an aluminum guitar designed and manufactured by NOAH, an Italian small–medium enterprise that creates handicraft guitar used by some of the most famous players in the world.
9.2. Aluminum guitars versus wooden guitars: The NOAH case study
Generally, electric guitars' components are made of different kinds of wood (e.g., rosewood, maple tree) according to their function. This is because of both historical reasons (in ancient time, wood was the only suitable material) and practical ones (touching wood is a pleasure for players' hands, wood is light, etc.). The usage of wood has some drawbacks: first of all, wood is an “alive material” that modifies its characteristics. To avoid such problems, wood that is employed in the manufacturing of electric guitars is typically seasoned and expensive.
Another problem of wood is that it can be damaged very easily in case of collisions. To solve such problems, guitar manufacturers have experimented with other materials. In particular, metals are considered good substitutes of wood, because they are not deformable. Unfortunately, the adoption of metals leads in most case to obtain too heavy products. Moreover, metals are cold, and they cause bad feelings in guitar users who touch them when playing.
For this reasons, wood is still the most suitable raw material to use in the manufacturing of electric guitars. Some exceptions can be found: NOAH Guitars is the Italian leader in the design and manufacturing of aluminum guitars. NOAH experts have devised a process to produce guitars with characteristics very similar to more traditional ones exploiting their know-how in working with aluminum.
9.3. The NOAH guitar: A collaboration within a network of SMEs
It is important to notice that the NOAH method concerns the design and manufacturing of guitar bodies: other parts, like for example, the neck and headstock are still made of wood. Moreover, although NOAH is responsible for the design of every part, their manufacturing is contracted out to a set of SMEs chosen by NOAH on the basis of two main principles: geographical closeness, to reduce transportation timing and costs, and excellence, to guarantee the maximum level of quality of manufactured parts.
The body is obtained from a unique piece of aluminum that is roughly processed by a Finite Element Machine according to a computer-aided design (CAD) model. The result is a hollow body where other guitar components (pickups, bridge, volume, tone controls, etc.) will be located. The body is then refined to delete imperfections, to round off edges, and make aluminum polished. An example of a typical NOAH guitar is shown in Figure 9. The adoption of aluminum provides NOAH guitar bodies with a natural capability to minimize noises because of the interference caused by pickups. Moreover, aluminum bodies can be maintained very easily: because the body is a sort of box where most of the functional parts of the guitar are placed (e.g., bridge, pickups, controls), the body has been designed and manufactured to allow an easy access to such components in case of need, for example, to substitute a broken part. Although this is difficult in the case of wooden guitars, because wooden bodies are built up starting form a unique piece of wood, without junctions, NOAH guitar bodies are made of two distinct parts, the frontal container and a cover, that are fixed to the frontal container by means of screws. In this way, it is really simple to manage other components of the guitar by removing the cover. This kind of solution is not applicable to wooden guitars, because the body profile is too thin to allow the realization of holes for screws.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626220056-82712-mediumThumb-S089006040999014X_fig9g.jpg?pub-status=live)
Fig. 9. A NOAH guitar with an aluminum body. [A color version of this figure can be viewed online atjournals.cambridge.org/aie]
Another important innovation by NOAH experts is their attempt to reduce the bad feelings in players because of the contact with cold surfaces, both from the manufacturing process and raw material adoption perspectives. The last phase of the manufacturing process is anodizing, through which the aluminum assumes characteristics less unfamiliar in terms of touching perception by the user. Moreover, NOAH experts research is continued in the field of raw material testing, with the experimentation of new types of aluminum and their adoption in case of success.
Finally, NOAH electric guitars are also appealing from the aesthetic point of view. Aluminum is buffed by hand to delete imperfections, and also the mounting of other components like pickups and bridges on it are the result of deep analysis.
Thus, we can say that the final product is the result of an intense negotiation process among NOAH experts where three distinct competencies emerge:
• functional competencies, concerning the property of the guitar from the playing point of view, for example, the reduction of noise;
• procedural competencies, concerning how to design the body exploiting CAD technologies to properly feed machineries that will produce them starting from pieces of aluminum and preserving its functional features; and
• aesthetic competencies, related to the design of guitars that can be appealing for a customer and can characterize them as artistic objects as well as good musical instruments.
Each of these competence is owned by subgroups of experts in NOAH, as shown in Figure 10, where it is possible to identify people skilled in playing guitars who are able to recognize benefits/drawbacks on the sound quality coming from the adoption of a specific design choice (i.e., the performance designer), expert people in the field of aluminum properties analysis and metal treatment (i.e., the production process designer) and people with deep know-how in the design of artistic objects (i.e., the features and shape designer). Moreover, as introduced above, NOAH collaborates with a small set of enterprises for the manufacturing of different guitar parts. This collaboration has become crucial when the number of guitars to produce has grown, thanks to the success of the product. At the moment, three main partners can be distinguished: two mechanical workshops (i.e., MW in Fig. 10) in Milan and a maker of stringed instruments in Cremona (i.e., MSI in Fig. 10), a small town near Milan worldwide famous for the high quality of its professionals. Although the two mechanical workshops are responsible for the manufacturing of all the guitar's aluminum components (from the body to the screws) by means of finite element machines and according to NOAH requirements, the maker of stringed elements produces the neck, the headstock, and the wooden parts to preserve quality and appeal of the final product. This set of SMEs constitutes the network involved in the design and manufacturing of NOAH guitars.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215058-04638-mediumThumb-S089006040999014X_fig10g.jpg?pub-status=live)
Fig. 10. The network of SMEs involved in the NOAH Guitar design and manufacturing.
The interest on NOAH and its network from the KM perspective derives from the nature of collaboration among these people to make possible to integrate all competencies into a unique final product: the most important aim of the GUITAR HERO project is the definition of a common jargon and a shared knowledge model that makes possible to classify NOAH and its network as a Community of Practice, according to the classical definition by Wenger (Reference Wenger1998).
In fact, functional, procedural and aesthetic competencies are not considered in a synchronous way during the design and manufacturing of a new product, but as different and complementary aspects of the same problem. For this reason, the task to produce a new guitar is not considered as a sequence of atomic steps but as a negotiation process during which each competence is taken into account at the same time.
Thus, we can state that creativity in the context of NOAH is the capability of people belonging to the network to uniformly consider the different aspects of the knowledge involved that results into the reification of a concrete object that meets both functional and aesthetic requirements according to a manufacturing process that allows to preserve them.
The exploitation of this model should allow the development of useful functionalities to support NOAH in taking under control the manufacturing flow of their product, in the crucial switch from a handicraft production of few units per year to a limited serial production of some tens of product per year.
To reach this scope, the rest of the paper focuses on the representation of knowledge involved by means of ontologies, SA*-Nets, T-Matrix, and TS-CODE.
9.4. Structural and functional representation: Ontology and T-Matrix
The first objective of the project has been the complete characterization of electric guitar from the structural and functional point of view. To this aim, an ontology of the guitar has been defined and implemented in NavEditOW.
The hierarchical organization of the different concepts and individuals of the ontology is graphically represented as a dynamic tree. The aim of the navigation tree is to explore the ontology, to view classes and instances, to discover the relation between them.
The tree not only represents a hierarchy of classes connected by Is-A binary relations (shown in Fig. 11a) but also treelike connections of individuals for domain dependent classes of properties (e.g., Part-Of, isMadeOf). The parts of a guitar can be considered as classes connected by Is-A relation (e.g., a potentiometer is an electronic component, an electronic component is a hardware component, a hardware component is a main component).
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215108-03882-mediumThumb-S089006040999014X_fig11g.jpg?pub-status=live)
Fig. 11. (a) The Is-A-Tree of the guitar ontology, where each component is identified by a circle. (b) The Part-Of-Tree of the guitar ontology, where each part is identified by a rumble. [A color version of this figure can be viewed online atjournals.cambridge.org/aie]
As an example, shown in Figure 11b, the parts of a “physical” guitar can be linked to the guitar by a Part-Of relation. In this way, it is possible to group components under the subtree representing the main part they are all subparts of (e.g., starting from a guitar instance, it is possible to reach the potentiometer through the slim body node).
The root of the navigation tree is the OWL class Thing, and the rest of the tree is organized as follows: under the root node, there are the top-level classes (i.e., direct subclasses of Thing); each class can be expanded to show its subclass hierarchy and its individual members; individual-to-individual tree connections are defined according to a number of selected properties (e.g., Part-Of).
To distinguish between classes and individuals, they are represented with different colors and markers: a yellow circle for the classes, a violet square for the individuals. More individual properties (e.g., MadeOf, not shown in the figure) are considered by the system and blue squares are used to represent them.
The application allows the users to create, edit, and remove individuals of the ontology, their properties and, in particular, their labels. In fact, to ensure multilanguage support, it is possible to introduce several labels in different languages for every instance. Moreover, contextual editing, that is, the editing of individuals while browsing the ontology, is supported.
Although end-users may not be familiar with query languages, the possibility to perform expressive queries is supported. From one hand, a language as much as similar to well-known query languages for relational databases language should be preferred. On the other hand, interfaces enabling not expert users to query the ontology should be developed (e.g., query forms).
One kind of query interface is the SPARQL free query form, where users can write queries in the SPARQL language, display results in paginated tabular form, and navigate through results via hyperlinks. This interface is very flexible because the users can write arbitrary queries but is not suitable for end users who are not expert on the ontology domain.
Another kind of query interface is based on a predefined set of queries: Each query is composed of a description in natural language, a SPARQL query with optional parameters. Every parameter has a label, a type and, eventually, a restriction on the values (e.g., a parameter can only be valued with instances of a given class). For this interface, users can select a query by its description, define the query parameters' value and execute it.
The NavEditOW tool has allowed building a complete structural model of the guitar, from elementary components (screws, jacks, switches, etc.) to the most complex aggregates (body, neck, bridge, etc.). Anyway, this model has been useful only in the first part of the project, to understand which were the main components of the guitar. The real aim of the ontology we are developing is the definition of functional relationships and constraints among the different parts, to identify the functional systems that are responsible for the product performances from the user standpoint.
To this aim a second knowledge acquisition and representation campaign has been conducted with the scope to compile a T-Matrix, like the one depicted in Figure 12.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215106-97323-mediumThumb-S089006040999014X_fig12g.jpg?pub-status=live)
Fig. 12. A sketch of the T-Matrix for the acquisition and representation of functions and performances in the GUITAR HERO project.
The T-Matrix has been developed with the support of guitar users: this step has been crucial to define what kind of relationships exists between performances expected by the user and how the different components are arranged in the optimal configuration to meet the requirements. In Figure 12, three complete samples of such phase of knowledge representation are presented. Given the structural ontology previously defined, the aim of the first part of the T-Matrix is the identification of guitar functional systems, that is, the aggregations of guitar components that allow satisfying a specific function. For example, the function named Precision, that is, the guitar capability to maintain the string tuning when played hard, is supplied by a functional system made of neck, body, bridge, strings, saddles, pickup, and truss-rod. Although neck, body, and bridge are aggregates (they are semimanufactured parts produced by the network of SMEs according to a negotiation process), saddles, strings, pickup, and truss-rod are represented as elements in our ontology; at any rate, they are all arranged in the rows of the matrix, because they concur to the characterization of the Precision functional system.
The second part of the T-Matrix allows representing how the combination of functions, and consequently, of functional systems, influence the guitar performances. For instance, the style of the player is strongly influenced by the functional systems determining the Precision of the instrument and weakly influenced by the functional systems involved in vestibility (i.e., the guitar capability to be played comfortably) and timbre (the distinctive properties of the guitar sound) functions.
The definition of functions and functional systems is crucial to guarantee usage flexibility of the system by the user, because it allows enriching the guitar ontology with transversal relationships among parts. In this way, the user can be guided in the definition of more complex properties, configuring a new guitar not only in terms of features derived from simple aggregation or specification of parts (i.e., Part-Of and Is-A relations), but also of complex characteristics deriving from their combination to obtain given results (e.g., the guitar timbre must be clear).
9.5. Procedural and experiential knowledge representation: SA*-Nets and TS-CODEs
According to what we stated before, the definition of functional systems identification allow developing the procedural knowledge model involved in their design. In our framework, each functional system must be properly represented in terms of specific SA*-Nets, with the possibility to synchronized different design flows in case of need.
In the GUITAR HERO context, the procedural knowledge model starts from a CAD model of the guitar components. The NOAH expert involved in this fundamental step is the production process designer: on the basis of his experience, a complete SA*-Net has been projected, with a specific subnet for each functional system described in the functional ontology.
Figure 13 shows a sketch of such net concerning the Precision function. On the basis of ontology, Precision is because of a functional system made of five components: bridge, neck, saddles, strings, and truss-rod. Body, bridge, and neck need a specific process that can be divided into design steps (i.e., they are aggregates), each one represented by a transition in their SA*-Nets. The only transition in the truss-rod, saddle, and string SA*-Nets concerns the choice of a product from the market (i.e., truss-rod, saddle, and string are atomic elements). The fork transition specifies that each part can be designed asynchronously. Anyway, there are some influences among components suggesting the design of some parts before. Because the body is the component where every other part is fixed, it is very important that its design takes care of the exact number and position of other parts. For this reason, pickups and bridge should have been already defined when the body design process starts. For the same reason, the neck design depends on the kind of truss-rod to use, because it is crucial to know how the truss-rod will be positioned. Moreover, there is a very important dependency between body and neck: because the neck must be attached to the body, and they are made of different materials, the only way to put them together is by means of screws. Neck must be fixed very precisely and its dimensions must allow it to join perfectly the body in the right place: Precision would be significantly compromised in case of imperfections concerning this step.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215118-77454-mediumThumb-S089006040999014X_fig13g.jpg?pub-status=live)
Fig. 13. An SA*-Net representation of the design steps for the Precision functional system.
It is important to note that influences among components should be respected whenever a new guitar is going to be projected, whereas classical models are characterized by well-known parameterizations that allow the expert to design each part independently. The whole process ends when the join transition can be activated after the completion of every subnet specified.
The SA*-Net is a complete guide to the codification of knowledge based systems: each transition can be exploded into a collection of TS-CODEs to represent the experiential knowledge involved in its execution. Figure 14 shows an example of how the SA*-Net related to the Precision functional system can be explained by means of TS-CODEs.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215216-48469-mediumThumb-S089006040999014X_fig14g.jpg?pub-status=live)
Fig. 14. A TS-CODE sketch for the Precision functional system.
The main task is obtained as the merge of a collection of subtasks, each one identifying an aggregate shown in Figure 13. The output of the task is the right parameterization of the CAD models concerning the guitar parts on the basis of the desired precision value (HIGH, MEDIUM, or LOW).
Every subtask receives this value in input, and it is responsible for the right determination of parameters related to the guitar component represented by it (e.g., the body in Figure 13). Possible influences among subtasks are represented as procedure calls to the related subtask: for this reason, the correct definition of body attributes depends not only on the precision value received in input but also on the pickup and bridge parameters calculated by the related subtasks. Analogously, the body parameters will influence the definition of neck CAD model attributes in the Neck subtask.
9.6. Implementation: Managing guitar ontology by means of the NavEditOW tool
Up to now, the interest was mainly in the conceptual representation of knowledge involved in the guitar design. On the basis of it, a knowledge-based system to support the NOAH network is going to be developed. Indeed, the conceptual model is useful to uniform the different point of views of the network actors in representing the guitar parts: for example, it is important that the maker of stringed instruments, who is responsible for the manufacturing of the neck, conceives his/her activity not as a stand-alone step, but as a phase that must be strictly correlated to others to avoid mistakes or misunderstandings.
Anyway, as introduced above, the conceptual model must necessarily be mapped onto a suitable computational model: ontologies and SA*-Nets, from the knowledge engineering perspective, act as guidelines for knowledge acquisition and representation aiming at the definition of knowledge-based system development.
As a first step in the development of such system, an explicit representation of the domain ontology in the OWL language (see Fig. 15) has been proposed, exploiting the NavEditOw tool. This representation allows describing every concept into a formal language and to give each term a unique and explicit definition. This definition could be shared within the network, among experts, suppliers and customers (i.e., the guitar users).
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215414-84104-mediumThumb-S089006040999014X_fig15g.jpg?pub-status=live)
Fig. 15. The guitar ontology and an example of consistency check on it. [A color version of this figure can be viewed online atjournals.cambridge.org/aie]
With an ontological representation of the components constituting a guitar, it is possible to automatically generate the complete set of the physical elements required to manufacture the product. The generated bill of material (BOM) accurately lists all parts and raw materials needed to make a unit of product, as depicted in Figure 16. An interesting aspect is the flexibility of this ontology-based BOM: for instance, if we assert that a guitar body requires a bridge, we will be able to choose either a Bigsby or a fixed bridge, because both Bigsby and fixed bridge are subclasses of bridge. Thus, an OWL reasoner will be able to infer that the instances of subclasses are also instances of a superclass.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary-alt:20160626215456-27937-mediumThumb-S089006040999014X_fig16g.jpg?pub-status=live)
Fig. 16. Example of BOM generation. [A color version of this figure can be viewed online at journals.cambridge.org/aie]
Another feature provided by OWL, and inherited by NavEditOW, is the ability to automatically classify the instances of the ontology. In the guitar domain (see Fig. 17), a “LowNoiseGuitar” has been defined as a guitar with an aluminum body or a guitar with a multicoil pickup. NavEditOW is able to discover every guitar with these features and to assert that it is a low noise guitar.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20160328100453852-0862:S089006040999014X_fig17g.jpeg?pub-status=live)
Fig. 17. Automatic classification. The reasoner infers that Body001 is an instance of AluminumBody, and thus Guitar001 is an instance of LowNoiseGuitar. [A color version of this figure can be viewed online at journals.cambridge.org/aie]
One more example: a “FineTuningGuitar” is defined as a guitar with single saddles or truss-rod adjustable on the headstock. The first definition concerns the regulation of strings: as introduced above, single saddles allow a more precise regulation than double ones. The second definition regards the regulation of neck against deformations according to the principle that a truss-rod adjustable on the headstock is more efficient than a truss-rod adjustable on the body. Every guitar with at least one of these features is an instance of this class. Because the two classes “LowNoiseGuitar” and “FineTuningGuitar” are not disjoint, a guitar can be classified at the same time as low noise and fine-tuning.
To understand the improvement given by the knowledge-based approach to support the decision-making process in the design and manufacturing of electric guitars, the use case shown in Figure 18 may be useful. Let us suppose that a customer asks NOAH for a guitar with specific features: a low noise guitar. NOAH has two possibilities to meet requirements: searching for an existing guitar with such features in the ontological repository or designing a totally new guitar.
![](https://static.cambridge.org/binary/version/id/urn:cambridge.org:id:binary:20160328100453852-0862:S089006040999014X_fig18g.gif?pub-status=live)
Fig. 18. A use case.
Generally, a good choice could be to check the existing archive of products and decide to build a new one if and only if there is no product presenting the required features. NOAH can extract the list of the individuals belonging to the “LowNoiseGuitar” class. Thanks to the automatic classification provided by NavEditOW, all the guitars that are classified as “low noise” will be inferred as a set of instances of the “LowNoiseGuitar” class. If the set would be empty, NOAH will be notified, building a totally new guitar.
Otherwise, NOAH will be able to select a guitar class from the ontology, compute the BOM, and select all the components. Then, the system will check for the selection of all the required components, and eventually notify the user in case of omissions. The new guitar will be automatically added to the ontological repository, so that it will be chosen in the future if a new customer requires a guitar with the same features.
9.7. Discussion
The GUITAR HERO project can be considered from different perspectives, as knowledge-based system concerning an innovative domain, a design support system, a system for the preservation of cultural patrimony and creativity of handicraft and SMEs.
About the first point, it is important to highlight that guitar domain has been already explored by computer science (see, e.g., Radicioni and Lombardo, Reference Radicioni and Lombardo2005), but previous works in this field were mainly characterized by the analysis and reproduction of fingering methods for learning systems (Motokawa and Saito, Reference Motokawa and Saito2006), classification of playing styles (Izumi, Reference Izumi2002; Kerdvibulvech and Saito, Reference Kerdvibulvech and Saito2007), or tablature generation for electronic simulation of melodies (Miura et al., Reference Miura, Hirota, Hama and Yanagida2004; Tuohy & Potter, Reference Tuohy and Potter2006) rather than the attempt to build complete knowledge models for supporting the manufacturing of products.
With respect to the cited works, the GUITAR HERO project is devoted to the application of knowledge engineering and management techniques rather than traditional CSP and vision-based ones adopted in this field.
About the second point, the main interesting feature of GUITAR HERO project is the adoption of ontologies for representing complex objects from the functional point of view. In this sense, the project exploits a conceptual framework (Colombo et al., Reference Colombo, Mosca and Sartori2007b) already tested in the past (Colombo et al., Reference Colombo, Mosca, Palmonari and Sartori2007a; Bandini et al., Reference Bandini, Manzoni and Sartori2008). This framework is very suitable to deal with design and manufacturing problems, because it allows giving a complete representation of subsystems a complex object is composed of, describing their role in delivering functionalities.
The third issue is probably the more interesting, because it concerns the development of support systems for organizations characterized by scarce level of computer science technology. Indeed, the real innovation of the GUITAR HERO project is the product it is focused on, which is the result of a completely handicraft manufacturing process. The challenge is how to build an effective knowledge-based system for a problem where no formal representation of the decision-making process is available, and creativity of experts is the key factor for success.
The functional representation adopted allows describing the properties of a complex object as they emerge from the underlying structure of relationships among functional subsystems: in this way, the system is able to classify the request of a NOAH customer according to the archive of already manufactured products, suggest which kind of raw material or semimanufactured parts to buy and keep NOAH people in touch with collaborators, like guitar players or makers of stringed instruments.
10. CONCLUSIONS AND FUTURE WORKS
This paper has presented a conceptual and computational framework to support networks of SMEs in the design and manufacturing of handicraft products.
This framework is based on the integration of tools to acquire and represent three different kinds of knowledge involved: ontologies for functional knowledge, SA*-Nets for procedural knowledge, T-Matrix and TS-CODE for experiential knowledge. The combination of these four tools allows describing a complete KA for design.
From the computational point of view, the NavEditOW application has been introduced as a very flexible and usable tool to browse, edit, and query ontologies written in the OWL language. The most interesting feature of NavEditOW is the possibility to invoke its functionalities over the Web, with great benefits about the sharing of knowledge among networks of SMEs involved in the manufacturing of a product.
As a case study the GUITAR HERO project has been presented, which is a collaboration between the Research Center on Complex System and Artificial Intelligence of the University of Milan–Bicocca and NOAH Guitars.
The project scope is to design and implement a knowledge-based system for supporting the creativity of NOAH experts in designing and manufacturing electric guitars with aluminum bodies.
The decision-making process in this field involves different kinds of knowledge, which must be properly captured to understand how the different components of the guitar can be related to each other, influencing final product features. In this sense, the adoption of ontologies as a conceptual framework for the representation and integration of knowledge is strategic, as well as the exploitation of NavEditOW to guarantee their easy navigation and management.
The adoption of NavEditOW has led to an easy and quick access to the system through the Internet: this possibility is a great benefit for NOAH, which should allow a more efficient management of orders to suppliers, communication among people, and so forth.
Moreover, the definition of a knowledge model shared among the SMEs belonging to the NOAH network is a significant support in the generation of common jargon among them. This is the first step toward the creation of a community of practice involved in the design and manufacturing of electric guitars rather than a simple network of collaborators. At this point, feedbacks received by experts are encouraging: the ontological model of electric guitars is consistent and expressive.
At any rate, a lot of work must be done to reach the final goal: in particular, computational SA*-Nets must be implemented starting from the conceptual model created up to now. The implementation of SA*-Nets as a collection of tagged XML files is currently ongoing; then an opportune SA*-Manager will be designed and coded to describe computationally the navigation of the SA*-Nets according to the rules previously introduced.
ACKNOWLEDGMENTS
The authors thank NOAH experts for their support in writing the paper, and in particular, Gianni Melis and Mauro Moia, whose competencies and expertise we have tried to model in the current version of the system. Special thanks to Andrea Bonomi and Andrea Fulciniti for their work on the implementation of the system.
Stefania Bandini is a Professor in the Department of Computer Science, Systems, and Communication at the University of Milano–Bicocca, where she teaches artificial intelligence and knowledge engineering and expert systems courses. Her research activity concerns artificial intelligence, knowledge-based systems, KM, and discrete dynamical systems. She is the founder and Director of the Complex Systems and Artificial Intelligence Research Centre.
Fabio Sartori is an Assistant Professor in the Department of Computer Science, Systems, and Communication at the University of Milan–Bicocca. He received a PhD in computer science from the University of Milan–Bicocca in 2005. He is involved in research and teaching activities. Dr. Sartori has taken part in many research projects in the knowledge management area, involving both academic and industrial partners.