2.1 The Terra Modena network

The network of SMEs (see Figure 1) considered as a case study in this paper is devoted to the design and manufacture of a supermotard bike. This product is a kind of hybrid object, since it has the characteristics coming from both the enduro and highway sectors. For example, the driving position on a supermotard bike is typical of enduro, as well as some parts of it (e.g. suspensions), while performances (e.g. speed) are very similar to a highway vehicle. For this reason, the project and manufacturing of a supermotard motorbike requires very deep knowledge in both fields and the ability to manage heterogenous aspects in engineering design.

Figure 1

The partners involved in Terra Modena 198 design and manufacturing

Terra Modena 198 is produced by an Italian SME called I-TEA. I-TEA is located in one of the most important Italian regions from the automotive sector point of view, that is, Emilia Romagna. There it is relatively easy to find experts in this field. I-TEA is the place where the different parts of the bike are finally assembled, but each of these components is produced by external partners. The partners of I-TEA are chosen according to a couple of constraints: proximity constraint, that means to find a partner for the realization of a bike part near to I-TEA, in order to save production costs and times; excellence constraint, that means to choose the best partner in Italy or outside Italy in case of proximity constraint unsatisfaction, in order to be sure that the manufactured parts will be perfect. Inside the network, I-Tea acts as a sort of communication center, managing the interaction among partners and evaluating results of different design activities.

2.2 The Terra Modena 198 life cycle

It is important to highlight that the decision-making process concerns all the functional parts of the bike except engine and transmission. In particular, from the point of view of partners’ interactions, the life cycle of Terra Modena 198 can be summarized as follows: Design, I-TEA decides the bike aspect and talks about it with a partner who is responsible for the definition of the three-dimensional (3D) models of all the components. This step ends when I-TEA accepts the 3D layout; Engineering: the layout is transformed into the motorbike matematica that is a complete, virtual and quantitative model of the final product. This step is accomplished by the I-TEA Engineering Department; Modeling and Manufacturing: starting from the Matematica, a consortium of three partners collaborates to build the bike components. First of all, a prototype of all the components considered in the first two steps is defined. The prototype is typically made in wood or polystyrene. Then, the prototype is transformed into carbonium and steel components of the final product. At the same time, the electronic system is also produced, thanks to the collaboration among three SMEs specialized in the manufacturing of electronic circuits and cables; Assembling: finally, all the bike parts are assembled by I-TEA mechanics. The detection of errors is made at this step, with the consequent, possible revision of one or more of the previous phases. At the end of the assembling phase, the bike is ready to be tested.

The most important step of the lifecycle is the modeling and manufacturing one: this is because during this phase I-TEA does not have full control on the decision-making process, and the interaction among partners involved in the design and manufacturing of carbonium, steel and electronic parts of the bike could produce something which is significantly different from the initial requirements or which is difficult for the mechanics to assemble.

Another problem arising from the complexity of the relationships among network partners is the management of atomic and semi-manufactured parts of the bike: it is possible that during the assembling phase some components of the final product cannot be completed due to the absence of some of them.

A knowledge acquisition campaign has allowed us to verify the reasons for these problems. We understood that the most important cause of difficulties in correctly accomplishing all the phases of the lifecycle is that each partner does not have a clear and complete view of the bike: in other words, each member of the network executes his/her own task without thinking about possible unpredictable critical situations that could emerge from his/her mistakes or misunderstandings.

Thus, the main problem to solve in the case of Terra Modena was the creation of a tool to promote knowledge sharing among the network enterprises. For this, our solution has exploited the semantic Web paradigm that can give a shared definition of the supermotard bike, as well as a clear identification of each SME role within the decision-making process through the use of functional ontologies. The next sections are devoted to describing the conceptual framework we have developed, as well as the computational tool adopted for the navigation, editing and querying ontologies over the web, in order to deal with the geographic distribution of network partners.

3.1 Knowledge management for small–medium enterprises

There has been a great deal of research in the KM context, both from the theoretical and the practical standpoint to support SMEs in their day-to-day activities and to join SME networks. From the theoretical point of view, many conceptual framework 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 contribution 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, on the other hand it is a drawback when looking at the consequent vulnerability in terms of loss of key personnel.

This is probably the key aspect in dealing with 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 the 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 then be the representation of knowledge in order 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 to increase 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 this experience, candidate profiles were compared according to a case-based reasoning approach (Aamodt & Plaza, Reference Aamodt and Plaza1994).

It is still very difficult to build effective KM systems for networked SMEs, due to 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 a 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 in 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 knowledge about the construction domain; the domain knowledge is then structured and classified according to its use into specific meta models, suitable for building knowledge repositories for construction industries, called CIK (construction industry knowledge).

This model contains information and knowledge about products, processes, problems, best practices, legislative issues and so on. It is used by the KM system for exporting two kinds of functionalities: customer needs management (CNM) and knowledge community support (KCS).

The second functionality is more interesting from the KM perspective, since it concerns the development of technologies, methods and tools to support knowledge sharing and maintenance over a web-based architecture. For this, semantic Web technologies are fundamental in order to provide systems with the capability to retrieve complex and heterogeneous information, generated both internally and externally for 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 mechanical product that is the result of a collaboration among a collection of SMEs. Through the use of upper-level functional ontologies and the semantic web approach, it has been possible to help the network overcome problems in communication due to the lack of an opportune technological infrastructure. Consequently, the development of a shared model of knowledge involved in the decision-making process has been possible. This has given a clear definition of roles and the implementation of ERP functionalities that are very useful to solve organizational problems.

3.2 Functional design ontologies

Traditionally, researches on ontology in Computer Science regard the development of conceptual and computational frameworks to manage the negotiation and sharing of meanings among different agents or communities (Bouquet et al., Reference Bouquet, Don and Serafini2002). In these frameworks the problem that ontologies must solve concerns the definition of a common terminology with which agents and communities can efficiently exchange and search useful information and structured data.

The development of semantic applications based on ontologies can take advantage of many results and tools. In particular, the languages of the OWL family offer the possibility to share ontological knowledge over the Web through XML-based mark-up languages; these languages are provided with formal semantics based on Description Logics, and it is possible to reason on the represented knowledge by exploiting off-the-shelf reasoners and inference engines (e.g. Tsarkov and Horrocks, Reference Tsarkov and Horrocks2006). Querying languages such as SPARQLFootnote 1 have been defined and are provided by most of all the most-used ontology repositories: among them, NavEditOW is a tool supporting the rapid design and development of semantic Web applications based on OWL-DL ontologies; for a complete overview of the application we refer to (Bonomi et al., Reference Bonomi, Mosca, Palmonari and Vizzari2007), where the relationship between this application framework and relevant related work is also discussed. The main functionalities with respect to ontology navigation, editing and query that the NavEditOW offers to designers of semantic Web application are summarized in Section 4.

From the perspective sketched above, ontologies can be exploited to exchange knowledge, and in particular, by using the Web as a communication medium. The above-mentioned KNOW-CONSTRUCT project (Soares et al., Reference Soares, Simoes, Silva and Madureira2006) exploits ontologies from this perspective. However, the ontology-driven applications that form the basis, particularly when their design is supported by state-of-the-art tools like NavEditOW, require the definition of OWL-based ontologies. The definition of ontologies is time-consuming and requires expertise in knowledge representation, in particular when expressive axioms are exploited to support automated reasoning. Regarding the domain addressed in this paper, that is, the design of complex mechanical objects, different ontological approaches have been proposed for the development of computational models supporting engineering design activities. At a high level of abstraction, Engineering Design consists in taking actions on the structure of an object (on its parts), according to requirements and high-level specifications. A number of references in literature (Umeda et al., Reference Umeda, Ishii, Yoshioka, Shimomura and Tomiyama1996; Bracewell & Wallace, Reference Bracewell and Wallace2001; Chiang et al., Reference Chiang, Pennathur and Mital2001; Deng, Reference Deng2002; Kitamura et al., Reference Kitamura, Sano, Namba and Mizoguchi2002) indicate that the competence of engineering designers is related to their ability to consider functional constraints over the parts of the objects they are designing. The traditional engineering design research community has widely accepted this conceptual design methodology (Gero & Maher, Reference Gero and Maher1997): first, a designer determines the entire function of a design object by analyzing the specifications of the product to be built. He/she then recursively divides the function into subfunctions, a process that produces a functional organization. In correspondence to each subfunction, the designer uses a catalogue to look up the most appropriate elements (a component or a set of components) that are able to perform the functional requirement. Finally, the designer composes a design solution from those selected elements.

Here, 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 that realizes that function (Chandrasekaran, Reference Chandrasekaran1990). As a result, a designer obtains a micro-macro hierarchy of functions that are projected on the aggregate of parts which 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. In other words, ontological knowledge on functions is put into action by designers for describing design entities in terms of part-whole relations induced by the functional decomposition (Gero & Maher, Reference Gero and Maher1997).

Functional ontologies in Ontological Engineering have been properly developed in order to design knowledge bases representing the conceptual association between the expected effects of the devices and the ways of achieving these effects (Chandrasekaran et al., Reference Chandrasekaran, Josephson and Benjamins1999; Chandrasekaran & Josephson, Reference Chandrasekaran and Josephson2000). A functional representation is mainly aimed at giving an integrated description of what the design object has to achieve (i.e. its functions and behaviors) from how it can achieve its goals (i.e. its structure) (Gero, Reference Gero1990; Stahovich et al., Reference Stahovich, Davis and Shrobe1993; Umeda & Tomiyama, Reference Umeda and Tomiyama1997).

As discussed in Colombo et al. (Reference Colombo, Mosca and Sartori2007), these knowledge models have been traditionally inspired by the Function–Behavior–Structure (FBS) model (Gero & Kannengiesser, Reference Gero and Kannengiesser2003), a well-known conceptual schema representing the typical life cycle of a decision-making process in designFootnote 2.

Once the general map between the expected effects of the devices and the ways of achieving them has been realized (case studies and applications can be found in Kitamura et al. (Reference Kitamura, Sano, Namba and Mizoguchi2002)) these knowledge models can be exploited either as knowledge-bases to the support of computer aided design systems (Chandrasekaran & Josephson, Reference Chandrasekaran and Josephson2000; Gero & Kannengiesser, Reference Gero and Kannengiesser2003) or as metadata for functional annotations supporting document management services (Kitamura et al., Reference Kitamura, Washio, Ookubo, Koji, Sasajima, Tafakuji and Mizoguchi2006).

Especially in Ontological Engineering (Kitamura et al., Reference Kitamura, Sano, Namba and Mizoguchi2002) functional descriptions are typically aimed at giving a conceptual map over general engineering domains (mechanical, electronic, etc.). The assumptions that drive the functional models arrangement are normally rooted into physics (Umeda et al., Reference Umeda, Ishii, Yoshioka, Shimomura and Tomiyama1996). In other words, artifacts are conceived as material substances for quantitative physical forces (so-called device ontologies) and functions are seen as labels for collecting different objects under a same behavior.

The above-discussed models agree at a certain extent on the adoption of the FBS model in the field of Engineering Design. E-Manufacturing of mechanical products involving networked SMEs is basically concerned with objects of the same nature of the objects the Engineering Design deals with. Therefore we argue that the above-discussed approaches can be elaborated in order to develop a reusable upper-level functional design ontology (UFDO) that could be helpful in order to support semantic-intensive E-Manufacturing applications. We argue that such ontological descriptions of mechanical products can be profitably spent in order to face a well-known engineering activity bottleneck that the design process suffers from, especially in the case of networked enterprises.

To the best of our knowledge an OWL-DL formalization of such an ontology is not provided in the literature. A work embracing this Engineering Design perspective for semantic document management providing metadata for functional annotations is the above-mentioned (Kitamura et al., Reference Kitamura, Washio, Ookubo, Koji, Sasajima, Tafakuji and Mizoguchi2006). However, this ontology is aimed at providing generic classes of various types of functions, and it does not formalize the overall relationships between the structural and functional representation of objects.

The UFDO proposed here basically agrees on the main principles of the FBS-based models; in particular, the idea of providing a joint representation of the functional and the structural aspects of objects, the idea of representing these aspects through functional decompositions and structural mereologies and the idea of establishing connections between the two perspectives are at the basis of our UFDO.

The UFDO proposed then extends these ideas introducing a new classification of functions and design objects orthogonal to the classification related to functional decomposition. Moreover, the different design actors and the businesses involved in the manufacturing process are also explicitly represented in the ontology.

Instead, we do not treat behaviors and functions separately; in fact, taking behaviors into account and relating them to functions involves very rich and technical knowledge about the domain, which is difficult to capture, and is not very useful if there is no need to reason on how the functions are carried out (this is the case of computer-aided design though). In our UFDO, the device functional representation essentially aims to model the totality of the design constraints concerning both the behavioral and teleological guidelines together with the topological arrangement relating to the object structure. The functional decompositions of the design objects provided in this paper are driven by a qualitative rather than a quantitative understating of functions. This makes our approach different, for example, from Kitamura et al. (Reference Kitamura, Sano, Namba and Mizoguchi2002) and Umeda et al. (Reference Umeda, Ishii, Yoshioka, Shimomura and Tomiyama1996).

5.1 The functional and structural mereologies in design objects

The representation of the design objects is based on a functional perspective and concerns two kinds of knowledge about them: (i) behavioral and teleological knowledge (functional knowledge); (ii) structural knowledge. Behavioral knowledge concerns the behaviors of design objects while the teleological one concerns the goals assigned to these behaviors. In other words, behavioral knowledge involves competencies regarding the physico-mathematical models ruling the design object behaviors, and it is mandatory for establishing the design object structure. On the other hand, teleological knowledge involves competencies for connecting a specific design object behavior to its proper mission. Teleological knowledge copes with the selection of the useful design object behavior, which is able to satisfy the design object goals, while behavioral knowledge regards the synthesis of design object structure. In this ontology they have been condensed into a functional representation providing a qualitative representation of functions under the top-level Function.

Structural knowledge concerns a qualitative mereology representing the design objects according to their specular functional organization—under the top-level concept DesignObject—and a quantitative representation of a number of structural parameters—under the top-level concept StructuralParameter.

The knowledge about functions is represented through a functional decomposition, that is, a hierarchy of functions organized along the binary relation needA. A function f ₁needA function f ₂if and only if f ₂needs to be performed in order to properly carry out f ₁. At the top of the hierarchy there are the ‘Top Functions’ (TopFunct), that is, functions that are not needed by any other functions; at the bottom there are the ‘Ground Functions’ (GroundFunct), that is, functions that do not need any other function; any other function in the ontology refers to the class of ‘Sub Functions’ (SubFunct), that is, functions that may need some other lower-level functions and that are needed by higher-level functions.

On the other hand, ‘Design Objects’ are basically organized in a mereology by means of the partOf binary relation (and its inverse hasPart); elements of this mereology are identified according to functions, and therefore we will refer to it as a functional mereology. The functional mereology unfolds specularly with respect to the functional decomposition organization: with the ‘Top Functional Systems’ (TopFSys) on top, ‘Sub Functional Systems’ (SubFSys) in the middle and ‘Ground Elements’ (GroundElement) at the bottom layer. The partOf relation has been axiomatized to be not transitive in order to trace direct mereological connections; instead, in order to exploit inference about transitiveness when needed, a new relation partofTransitive has been introduced as the transitive closure of the partOf.

The functional decomposition and the functional mereology are connected first through the binary relations hasA and perform (the inverse of the first one: hasA^– = perform). Each DesignObject is therefore designed in order to perform one and only one specific function, as stated by the following range restriction:

This relation between the design object mereology and the functional decomposition is so strong that design objects belonging to a specific class in the mereology can be defined on the basis of the function they perform according to the following axioms:

(1)

(2)

(3)

In this way it is possible to exploit inferential power in order to infer that design objects are of the subclasses TopFSys, SubFSys or GroundElement according to the function they are associated to. Obviously, it could be possible to specularly make the same assumptions on functions, even if in this project the perspective of starting from information about function decomposition to infer information about object classes seems more useful to domain experts. Figure 3 represents such logical dependencies (the arcs represent universal restrictions if it is not explicitly stated that the restriction is existential; for the sake of clarity, full names are used in the pictures instead of the abbreviations used in the DL formulas).

Figure 3

The figure depicts the functional decomposition in upper-level functional design ontology, and the specular mereological arrangement of design objects

5.2 The ‘fill’ and ‘remove’ perspective on design objects

Besides the mereological perspective described above, there is another relevant function and object classification in this context. According to the functional perspective on the design object mereology, both functions and design objects can be classified on the basis of the role they play in the design process. One of the outstanding traits that characterizes the design activity consists of a progressive configuration of functional building blocks (i.e. design object parts) put together in order to achieve a complete artifact aligned with the end user requirements. During this process, designers ideally start from some parallelepiped and give a form to the design objects by adding or removing portions of matter. Once a geometrical entity (e.g. a parallelepiped) has been defined according to the functions it has to carry out, it is then assembled together with other functional building blocks until the design object is a complete whole. Thus, the design object parts can be conceived as aggregates of geometrical entities, each playing a different role in the iterative building of a single functional feature. A peculiar tract of the UFDO presented here is the treatment of these distinctions in the ontology. Some geometrical entities are conceived of as fillers of the design object parts while some others are thought of as space to remove from matter.

In order to take into account the different roles that design objects can play in the design process, the two disjoint subclasses of function ‘Filling Function’ and ‘Removal Function’. On the counterpart, ‘Filling Design Objects’ and ‘Removal Design Objects’ need to be represented. These relationships between different types of functions (filling and removal) and types of design objects need to be analyzed and formalized; such relationships are not trivial, since the mereological structure of objects is relevant for the function they can actually perform.

In particular, a filling design object is designed to perform only a filling function, while a removal design object is designed to perform only a removal function:

5.3 Integrating the two perspectives on the design objects representation

The classification of functions according to the proposed functional decomposition and the classification of functions according to their role in the design process intersect in the following way: filling functions can be top, sub and ground functions; removal functions are only ground functions (i.e. they do not need any other functions in order to be properly carried out) and, as a matter of fact, they are associated only with ground elements. The following restrictions are therefore imposed on the UFDO:

Figure 4 provides a graphical representation of the connections between the ‘fill’ and ‘remove’ perspective and the mereological perspective on the representation of objects and functions. As said before, the functional decomposition is based on the needA relation that represents basic functional dependencies. Moreover, functions are connected to design objects by means of the hasA, perform relations.

Figure 4

The figure depicts the relationship between filling and removal functions in upper-level functional design ontology

According to the nature of the design process previously introduced, the ground elements represent the building blocks of the subfunctional systems that are gradually configured during the design process. However, these building blocks cannot be purely conceived as entities without parts. They are, in fact, subjected to a process of addition and subtraction of matter, according to the proper function they have to carry out. For this reason, we introduced the ground elements subdivision in the UFDO in ‘Removal Ground Element’ and ‘Filling Ground Element’ as follows:

On the basis of the introduction of these entities, it is possible to specify further kinds of ground elements, that is, the ‘Interrupted Ground Element’ that intuitively represent ground elements which have been excavated in different shapes in order to fulfill their function. Here below, the axiom representing this concept is presented.

Note that in the above formula we have introduced the madeIn relation in order to express the mereological relation holding between a GroundElement and the RemovalGroundElement (e.g. an oval shaped hole), where the second one is part of the first one. According to the intuitive meaning held by any removal activity within the engineering design process, we exclude the case that a removal ground element could be also applied to a removal ground element. As a consequence of this assumption, in the InterruptedGroundElement definition we assert that a ground element, which is an interrupted ground element, can never be a removal ground element.

On the other hand, it is well known to design experts that whenever a subtraction of matter is applied to a component actively performing some function, a reinforce must be done. For this reason the ‘Reinforce Ground Element’ concept has been introduced as follows:

Nonetheless, this definition has been exploited to define the ‘Reinforced Ground Element’ concept, that is, a ground element ‘made on’ another ground element.

As for the madeIn, the madeOn relation must also be conceived as a mereological relation living between the ReinforcedGroundElement and the ReinforceGroundElement, where the second one is part of the first one. These relationships are represented in Figure 5. Even if it is beyond the purposes of this paper to proceed further with the analysis of the relationships holding between reinforced ground elements and interrupted ground elements, it is useful to note that a large part of the creativity in design depends on them.

Figure 5

The figure depicts the relationships among reinforce, removal and filling design objects and the functions they perform

As for the physical characteristics of design objects, UFDO considers a set of ‘Structural Parameters’ (e.g. Weight, Volume, Chemical Composition) that a ground element has to satisfy in order to meet the specifications of the actors involved in the design process. The concept of StructuralParameter is therefore strictly related to the representation of the knowledge corpus concerning the social collaborative environment in which the design process takes place.

5.4 Actors involved in the design process

Along with the representation of functions and design objects we therefore need to represent knowledge about the actors involved in the design and production processes: the ‘Design Actors’. Specifications of the DesignActor concept are relative to the ‘Management’, ‘Engineer’, ‘Client’ and ‘Manufacturer’ actors. According to the collaborative nature of the design process, the design actors take part in the process by prescribing specific requests on the design objects.

This commitment of actors in the definition of design objects is represented by means of the relation prescribeA connecting DesignActor (the domain of the relation) to DesignObject (the range of the relation). In particular, we observe that: (i) Engineer and Client prescribe on GroundElement and on SubFSys, (ii) Manufacturer has no prescribing role and (iii) only Management has a prescribing role on TopFSys. This is stated by the following axioms:

The prescribeA relation represents the general commitment of actors to the definition of a design object. However, with respect to ground elements, this role can be more detailed, involving specification on the structural parameters for these objects. This association is represented by means of the role define, which is restricted to have DesignActor as its domain and StructuralParameter as its range. As one expects, a design actor defines the structural parameters of those design objects with respect to his/her prescriptive role (see the above axioms).

Two other relations are introduced in order to explicate the behavioral and structural constraints that exist among the different design object parts. These relations explicitly represent what kind of side-effects one has to consider when a prescription on structural parameters is stated. More precisely, the imposeA relation, linking structural parameters to structural parameters, expresses the condition in which a prescription on structural parameters of an object is mandatory with respect to a prescription on the structural parameters of another object; the conflictWith relation, linking structural parameters to structural parameters, expresses the fact that a prescription on structural parameters of an object can obstruct the structural parameters of another object.

Usually it is interesting to consult the ontology about this kind of relation, whenever the involved objects are designed and produced by different actors in the process.

Finally, along with the actors directly involved in the design process, we introduce the concept Business. This concept includes all the businesses that are involved in the manufacturing process. A Business is therefore connected with the DesignObject that it constructs by means of the role make. The different kinds of DesignActor are connected to Business by means of the role memberOf. In order not to define a complex ontology of businesses from scratch, we exploit the semantic Web approach, importing an existent ontology of businesses, namely the ‘eBiquity Contact Information Ontology’, developed by the UMBC eBiquity Research Group (University of Maryland, Baltimore County)Footnote 4. In this way, the UFDO can store business contacts according to standards of business cards.

6.1 The Terra Modena domain ontology

Formally, the Terra Modena domain ontology is a specialization of the UFDO presented above. The domain ontology basically introduces a number of instances to represent specific functions and design objects. Some domain-related attributes have been inserted to describe structural parameters. In the rest of the paper, we use a hybrid linguistic notation: UFDO has been formalized in English and the UFDO terms are written according to their English form; on the contrary, since the main actors of the project were Italian, the domain ontology has been represented using Italian terminology in the prototype; however, Figure 6 provides a graphical representation of the ontology in English terminology.

Figure 6

The functional ontology of Terra Modena 198 motorbike

Observe that the domain design objects and functionalities are represented with A-box statements. Hence, the users of the application can add or delete functions and design objects of interest through a Web-based interface, according to the functionality offered by NavEditOw and discussed in Section 4.

As introduced in Section 2 the top functional systems consist in the Supermotard bikes; the subfunctional systems (e.g. the Engine, Brakes, Chassis) are aggregate components that perform the subfunctions of a motorbike (e.g. the Propulsion, Slackening, Road-Holding), and the ground elements are atomic ingredients of these aggregate components (e.g. the Pistons, Handlebar, Swingarm). The second layer from the top represents the set of subfunctions needed to achieve the top-level function (represented in the top layer). These functions are linked to the design objects, that is, subfunctional systems, performing these functions. These subfunctional systems are connected to the set of ground elements they are composed of.

6.2 Semantic queries and inference with the Terra Modena domain ontology

The formal representation given in the UFDO supports the representation of knowledge involved in the motorbike design and manufacturing processes along different directions.

First, the representation allows to build applications around a strong model of the knowledge behind the activities carried out by the stakeholders involved in the design and manufacturing of the motorbike; that is, to say that it allows a shared common view on different specific purpose applications. The semantic Web-based application allows to browse the knowledge represented providing a unified view on the overall knowledge related to the motorbike. For example, one can navigate through functions and discover which objects are designed to perform these functions. The motorbike components can be accessed by browsing the navigation tree; their properties can be visualized. Observe that the NavEditOw functionalities are exploited in order to provide a structured visualization of instance dependencies along the partOf relation. Figure 7 provides an example where the ‘sospensioni’ subfunctionalSystem is expanded and the properties concerning the ‘forcella’ ground element are shown.

Figure 7

The navigation of the ontology tree

Second, standard query languages such as SPARQL can be exploited to retrieve information according to the semantic model provided. SPARQL queries can be easily parameterized in order to provide users with user-friendly interfaces supporting the discovery of knowledge about specific object of interest. As an example, when a problem concerning subsystem occurs, often it is not easy to recall all the partners involved in the manufacturing of such a subsystem. With a simple parameterized SPARQL query, it is easy to retrieve all the elements a subsystem is composed of and to present contact information about the businesses involved in the provision of the components. Figure 8 shows that this information can be retrieved on the basis of the ontological model. Figure 9 shows results of a parameterized query related to the structural parameters of ground elements, that is, ‘forcella’ in the picture.

Figure 8

Supporting the semantic-based retrieval of information about the components of a subfunctional system

Figure 9

Information about the structural parameters of the component ‘forcella’

Third, automated reasoning techniques can be used. The reasoner completes knowledge inserted by users exploiting concept definitions. As an example, membership of design objects to classes is inferred on the basis of the axioms (1), (2), (3). Given a component of the motorbike together with its associated functionality, one can infer what kind of component this is, and therefore, what the mereological structure in which it is embedded is, what the design actors prescribing it are and, finally, how it is possible to optimize the whole production process in which the component is involved. Formally, the following statements are contained in the Terra Modena Knowledge Base:

Then, from axiom (2) one can infer that SubFSys(cambio001), that is, the cambio001 component is a subfunctional system, thus having parts performing specific ground functions.

SPARQL queries can fully exploit the semantic-based approach to knowledge representation. In fact, it is possible to combine reasoning performed by state-of-the-art reasoners (we used FACT++) with queries, and answering queries on the basis of the inferences performed. As an example, all the subcomponents of the motorbike can be retrieved since the reasoner completes the extension of the partOfTransitive relation.