Representing the Conceptual Design Process in Engineering using IAO and OBI

Abstract

Engineering and other areas from industry are increasingly of interest from the perspective of applied ontology. While several ontological approaches have been proposed to annotate the engineering design process, alignment with the Basic Formal Ontology (BFO) and the principles of the Open Biological and Biomedical Ontologies (OBO) Foundry remains largely absent. This paper addresses this gap by proposing an ontological representation of the product development process in engineering, with a particular focus on the conceptual design phase, based on Pahl and Beitz's wellknown engineering design approach. Based on the Information Artifact Ontology (IAO) and the Ontology of Biomedical Investigations (OBI), we develop a representation that accounts for the information content entities and processes central to engineering design. The paper reviews existing design ontologies, outlines our development methodology, and presents a BFO-compliant ontological representation of the conceptual design process. The proposed approach supports integration with domain ontologies that represent technical artifacts.

Keywords

• eol>engineering
• conceptual design
• product development process
• planned process
• IAO
• OBI1

1. Introduction

Engineering and other areas from industry are increasingly of interest from the perspective of applied ontology, for example, within the

Industrial

Ontology

Foundry (IOF) (oagi.org/pages/industrial-ontologies). Several ontological analyses have been offered to semantically annotate the engineering design process, particularly its conceptual phase [ 1 ], or production processes [ 2 ]. However, to our knowledge, there is no account of the design process that is in line with the Basic Formal Ontology (BFO) (github.com/bfo-ontology), and the principles of the Open Biological and Biomedical Ontologies (OBO) Foundry (obofoundry.org).

Motivated to fill this gap, this paper presents an ontology of the product development process in engineering, with a particular focus on the conceptual design phase. Built for integration with domain ontologies representing technical artifacts, it aims to provide a clearer ontological understanding of the design process and the ontology of technical functions. Doing so, we will

heavily rely on the Information Artifact Ontology (IAO, github.com/information-artifactontology) and the Ontology of Biomedical Investigations (OBI, obi-ontology.org).

The paper is organized as follows. Section 2 presents an overview of the product

development processes in engineering and existing engineering design process ontologies.

Section 3 details the methods and materials used, and Section 4 proposes reusing classes and

formal relations to represent the product development processes in engineering with a focus on conceptual design. Section 5 discusses the findings and concludes the paper.

In this paper, class names are written in italics along with their corresponding namespaces,

e.g., BFO:material entity. Relation terms, including the namespace of the source ontology, are written in bold, e.g., IAO:mentioned by. We mostly refrain from citing the namespaces of rdfs:subClassOf and owl:equivalentClass. Logical connectors are set in small all-caps, e.g.,

NOT or SOME. Table 1 lists all classes and relations imported from the OBO Foundry ontologies

with their labels, their unique OBO IDs in square brackets, and the full IRIs (Internationalized

Resource Identifier) as hyperlinks added to the OBO IDs. For example, the class BFO:material

entity is accompanied by [BFO:0000040], where the OBO ID is shown in the brackets and the corresponding IRI http://purl.obolibrary.org/obo/BFO_0000040 is embedded as a hyperlink.

A version of the OWL file is available on github.com/BiomimeticsOntologies/CDP.

Classes and relations imported from the OBO Foundry ontologies. We state their labels, their

OBO IDs in square brackets, with the corresponding IRI embedded in it as a hyperlink.

Classes

OBI:plan [OBI:0000260]

OBI:planned process [OBI:0000011]

Relations

RO:participates in [RO:0000056] RO:has participant [RO:0000057]

IAO:information content entity [IAO:0000030]

RO:concretizes [RO:0000059]

IAO:directive information entity [IAO:0000033]

RO:is concretized as [RO:0000058]

IAO:plan specification [IAO:0000104]

IAO:action specification [IAO:0000007]

OBI:is specified input of [OBI:0000295] OBI:has specified input [OBI:0000293]

IAO:objective specification [IAO:0000005]

OBI:is specified output of [OBI:0000312] OBI:has specified output [OBI:0000299] IAO:mentioned by [IAO:0000143]

2. Background

2.1. The Engineering Product Development Process According to standard accounts, the life cycle of a product typically starts with a market need or problem and ends with its disposal. It includes, among other stages, product planning and designing, producing, testing, consuming, and recycling. Ontologically, we need to distinguish between at least two levels here: the abstract product type and its concrete instances. The outcome of planning and design is a plan specification for the product type itself, but the objects of production, consumption, and recycling are the particular instances of a product type. Pahl et al. [ 3 ] analyse the commonalities in systematic product planning approaches and present two overlapping process descriptions for product planning and for product development. The product development process includes both planning and design processes, and is divided into four main phases: (D1) planning and task clarification, (D2) the conceptual design, in which the design of the product is specified, (D3) embodiment of the design, and (D4) detail design, which specifies the production process.

Phases (D1) and (D2) of the product development constitute the product planning process, which is subdivided by Pahl et al. into six iterative phases, where the output of a phase is the input of the next one: (P1) analysing the situation related to market, product, company and its competitors, (P2) formulating search strategies based on the former phase, (P3) finding product ideas, (P4) selecting product ideas, (P5) defining product and its requirements. The sixth and final phase of the planning process is (P6) clarifying and elaborating on the product proposal; it coincides with phase (D2) of the product development process. Once all the stakeholders in the product development agree on the product planning output, the product design begins. Pahl et al. [ 3 ] note that a clear distinction between these main phases is not always achievable. Figure

1 illustrates our reading of the steps and intersections of the product planning, planning design,

and product development processes described in Pahl et al. [ 3 ].

This paper focuses on the second phase of the product development process, viz., (D2) the conceptual design phase. The conceptual design phase determines the principle solution that will be implemented in the embodiment design phase (D3). The design specifications defined in (D1) are achieved through a series of processes: (C1) identification of essential problems, (C2) establishment of functional structures, (C3) identification of working principles, (C4) selection of working principles, (C5) combination of working principles, and (C6) addition of construction parameters.

Identification of essential problems (C1) involves analyzing the design specification, or “requirements list” [ 3 ]. These problems are abstracted from what is particular and incidental to the task in order to clarify and refine the “crux of the overall problem” [ 3 ]. This abstraction enables a clear view of the overall function and task constraints. So, in (C2) establishment of functional structures, the complex task is divided into less complex ones. Accordingly, the overall function, which is the most complex, is broken down into simpler subfunctions. This process is called (C2.1) functional analysis. The outcome is a combination of individual subfunctions that results in a functional structure.

In (C3) identification of working principles, possible principles that fulfil these subfunctions are explored. As a single function can be fulfilled by various working principles and a working principle can fulfill multiple functions, it is critical to identify as many viable working principles as possible. However, the number of working principles is reduced through assessments of their mutual compatibility and their alignment with the task constraints in (C4) selection of working principles. In (C5) combination of working principles, selected working principles are integrated to form working structures. As there can be several working structures, choosing the most suitable structure for the fulfillment of the overall task is critical. Finally, in (C6) addition of construction parameters, working principles in the chosen working structure must reflect the physical effect and the geometric and material characteristics needed for the fulfillment of the corresponding function. These specifications are defined as the construction parameters. 2.2. Existing Engineering Design Process Ontologies In the literature, there are ontologies representing the product life cycle or a part of it [ 4–7 ], and ontologies representing the conceptual phase of the planning and design process [ 8, 9 ]. Our focus here is to formally represent the conceptual design phase. The existing product development process and design process ontologies mainly focus on a formalism for representing design activities in terms of input, output, and process. Sim and Duffy [ 10 ] developed an ontology of generic design activities based on the commonly accepted systematic design methods, including Pahl et al. [ 3 ]. The ontology has three highest categories, i.e., design definitions activities, evaluation activities, and management activities. Existing design knowledge is classified in terms of input knowledge, design activity, design goal, and output knowledge under the subclasses of these highest categories. Function, working principle, and [working] structure are mentioned as input and output knowledge, such as Knowledge of function to solution principle mapping/structural building block or Knowledge of function/subfunction decomposition. However, as the activities are categorized as design definition, evaluation, and management, this ontology provides a schema to represent a flow of a development process, but basic elements of the design process are not taxonomically classified.

Ahmed et al. [ 11 ] introduce the Engineering Design Integrated Taxonomy (EDIT), which is also called an ontology, for indexing, searching, and retrieving design knowledge. The highest categories of the ontology are design process, function, issue, and product. This ontology cannot provide us with a representation of the conceptual design process, as design process and product are not specified due that their instances are specific to a particular company, and, function includes types of engineering functions, issue contains the classes that refer to deliberations a designer must take into account while carrying out the design process. Thus, it is ambiguous how to include processes like the identification of working principles fulfilling an intended function.

Green et al. [12] present an “interim ontology” for the design process to encapsulate any

design domain. The highest classes of the ontology are input, process, and output. For instance, the market value of a social media webpage is categorised under input, the designed webpage is categorised under output, and coding that webpage in HTML is categorised under process. According to this approach, then, analyses of functions and identification of working principles are subclasses of design process structure, which is a subclass of process. However, for our purposes, this introduction cannot reflect the interrelations between functions and working principles in a conceptual design phase. Trumbach et al. [ 13 ] point to a lack of ontology “to reduce the uncertainty in technology development by better understanding the social, economic, and environmental changes”. In this respect, they built what they call an “important words ontology” for new product development, whose highest class is important words and its immediate subclasses are influence words, design words, construction words, geography, assets, and person-groups. The inclusion of ontological categories of the conceptual design process was never intended in this ontology.

As a consequence, we cannot reuse these ontologies for two reasons. First, the construction aims of the abovementioned ontologies do not align with our purpose of representing the conceptual design phase in detail. Second, none of them are BFO-conformant, and hence difficult to integrate with the OBO Foundry ecosystem. An alignment with the OBO Foundry ontologies is essential because we also want to cover biomimetic development processes, which need to refer to the domain of biology [ 14, 15 ]. In particular, we want to integrate the representation developed here with our core ontology for biomimetics, which imports many classes from OBO Foundry ontologies [ 14 ].

3. Methods

For developing our ontology, we applied the Open Biological and Biomedical Ontology (OBO)

Foundry Principles (obofoundry.org), which are intended to provide a suite of orthogonal and

interoperable ontologies. In accordance with the OBO Foundry Principles, we used the Basic Formal Ontology (BFO) as the top-level ontology, which meets the standards set by ISO/IEC 21838‑1 for top-level ontologies and promotes interoperability, standardisation, and reuse. From the OBO Foundry ontologies, we used in particular the Ontology for Biomedical Investigations (OBI) and the Information Artifact Ontology (IAO) to represent the planning and design processes of the life cycle of a product. Both ontologies are closely knit together. The development of the IAO was initiated from within the OBI community, and both ontologies import classes from each other (www.ebi.ac.uk/ols4/ontologies/iao). Figure 2 displays the classes from BFO, OBI, and IAO that we use for representing plans and processes.

We also aimed to reuse relations that have established themselves as standards in the OBO

Foundry (Table 2). In order to align with the class or relation definitions in IAO and OBI, we refrained from using the temporalised relations of BFO; instead, we used their non-temporalised superrelations. IAO and OBI import relations from the Relation Ontology (RO), and they have their native relations, which can share their labels with the ones in BFO. In such cases, we stated that (i) they are equivalent to the homonymous BFO relations when there seems to be no semantic difference between them, e.g., participates in [RO:0000056] is equivalent to the homonymous BFO relation [BFO:0000056], and (ii) the interrelation between the relations is specified, e.g., BFO:concretizes is a superrelation of RO:concretizes, as the former’s domain is wider than the latter. We did not encounter any inconsistencies due to our choice of relations.

A planned process realizes a plan, which is, in turn, the concretization of the plan specification [16, 17]. The following IAO axioms are especially important for this paper:

(i) OBI:planned process equivalentClass

BFO:realizes SOME (RO:concretizes SOME IAO:plan specification) (ii) IAO:objective specification BFO:continuant part of SOME IAO:plan specification (iii) IAO:action specification BFO:continuant part of SOME IAO:plan specification

The ontology has been implemented in the Web Ontology Language (OWL, www.w3.org/OWL)

using the Protégé 5.6.5 editor (protege.stanford.edu). We used Protégé’s built-in wizard to import the BFO with all its entities, their IRIs, labels, definitions, and other annotations. We imported relevant classes of OBI, IAO, and RO by using the OntoFox tool ([ 18 ], ontofox.hegroup.org) that builds on the Minimum Information to Reference an External

Ontology Term (MIREOT) method [19]. Finally, we used HermiT 1.4.3.456, an automatic reasoner available in Protégé, and approved the logical consistency of the ontology.

4. Results

It aims to represent the production development process, including planning and design

processes, that potentially start the life cycle of a technical artefact. Such a product can be a tangible entity, e.g., a tool or a robot, or an intangible entity, e.g., a strategy or an algorithm.

The instances of the former instantiate BFO:material entity [BFO:0000040] or BFO:object

[BFO:0000030]. The instances of the latter instantiate IAO:information content entity and its relevant subclasses. Moreover, not all design processes end with a technical artefact. Thus, a path from the plan to the product should enable ontology users to represent prototypes, unrealised plans, and products in the design process.

The endpoint of a design process is, however, not the product itself. While the product is the specified outcome of the production process, the outcome of the design process is a plan specification for how to produce the product. Following Pahl et al. [ 3 ], the design plan is the first step of the product development process, which clarifies the task to be completed at the end of the production process. Figure 3 shows the relations between plans and processes in the product development process in engineering.

Relation

RO:participates in [RO:0000056] RO:concretizes [RO:0000059] OBI:is specified input of [OBI:0000295] OBI:is specified output of [OBI:0000312]

Suggested Mapping to

BFO owl:equivalentProperty RO:has BFO:participates in participant [BFO:0000056] [RO:0000057]

Inverse Relation rdfs:subPropertyOf

BFO:concretizes [BFO:0000059] RO:is concretized as [RO:0000058] OBI:has specified input [OBI:0000293] OBI:has specified output [OBI:0000299]

Suggested Mapping to

BFO of Inverse owl:equivalentProperty

BFO:has participant [BFO:0000057] rdfs:subPropertyOf BFO:is concretized by [BFO:0000058]

A design plan is realized in a conceptual design process. A complete conceptual design process includes all the steps in the conceptual design phase (D2). The outcome of this process is the conceptual solution, which we call the construction structure plan, whose specification includes the of details of the embodiment of the design phase (D3) and the detail design phase (D4). The outcome of this plan is the product documentation ([ 3 ], p. 130; also called “production documentation” on p. 132 or simply “documentation” on p. 437), which includes parts lists, CAD models, drawings, and assembly instructions. It describes the technical aspects of how the product is made and the specific requirements for the production process. To ensure terminological consistency and to avoid confusion with IAO:document [IAO:0000310], we prefer to call it the production plan. A production plan specifies all the steps of a production process and its outcome, i.e., the final product itself. Although the production process is not a component of the product development process, introducing it provides a fuller description of the plan-to-product part of the product life cycle. We thus have the following three types of plans in our ontology: design plan subClassOf OBI:plan construction structure plan subClassOf OBI:plan production plan subClassOf OBI:plan

Technical artefacts are the result of a practice that begins with planning and a series of processes that realise the plan. A plan specification serves as a blueprint that may or may not be concretized into a plan (i.e., into an agent’s commitment for a certain action). We add the following axiom:

OBI:plan IAO:mentioned by SOME IAO:plan specification

Then, we can introduce the following classes, which are the specifications of the corresponding plans. For instance, a design plan specification serves as a blueprint for a design plan, or a production plan specification is a blueprint for a production plan when it is realized. We specify them by means of the IAO:mentioned by relation, design plan specification subClassOf IAO:plan specification design plan IAO:mentioned by SOME design plan specification construction structure plan specification subClassOf IAO:plan specification construction structure plan IAO:mentioned by SOME construction structure plan specification production plan specification subClassOf IAO:plan specification production plan IAO:mentioned by SOME production plan specification

Based on the IAO axioms (i) and (ii) cited in Section 3, we define the processes that constitute the parts of the engineering process (Figure 3):

conceptual design process subClassOf OBI:planned process conceptual design process equivalentClass

BFO:realizes SOME (RO:concretizes SOME design plan specification) construction structure process subClassOf OBI:planned process construction structure process equivalentClass

BFO:realizes SOME

(RO:concretizes SOME construction structure plan specification) production process subClassOf OBI:planned process production process equivalentClass

BFO:realizes SOME (RO:concretizes SOME production plan specification)

A plan is a realizable entity that inheres in a bearer who is committed to carrying it out [16]. A

plan specification guides a process where the bearer attempts to achieve some objectives by performing some actions. When a bearer adopts and acts upon the plan, the result is a planned process. Therefore, a plan specification details those actions and objectives. As such, IAO:plan specification has two parts: IAO:action specification and IAO:objective specification, where the former describes the bearer’s action and the latter describes the intended result of the plan.

Based on IAO axiom (iii) citied in Section 3, we specify the corresponding classes of action and objective specifications and establish their parthood relations to the relevant plan specifications:

objective design plan specification subClassOf IAO:objective specification objective design plan specification BFO:continuant part of

SOME design plan specification

action design plan specification subClassOf IAO:action specification action design plan specification BFO:continuant part of SOME design plan specification objective construction structure plan specification subClassOf IAO:objective specification objective construction structure plan specification BFO:continuant part of

SOME construction structure plan specification

action construction structure plan specification subClassOf IAO:action specification action construction structure plan specification BFO:continuant part of

SOME construction structure plan specification

objective production plan specification subClassOf IAO:objective specification objective production plan specification BFO:continuant part of

SOME production plan specification

action production plan specification subClassOf IAO:action specification action production plan specification BFO:continuant part of

SOME production plan specification

As mentioned above, action specifications are about the processes, while objective specifications

are about intended results. The following axioms state how processes and action specifications as well as plans and objective specifications are related via IAO:mentioned by. conceptual design process IAO:mentioned by SOME action design plan specification construction structure plan IAO:mentioned by SOME objective design plan specification construction structure process IAO:mentioned by

SOME action construction structure plan specification

production plan IAO:mentioned by SOME objective construction structure plan specification

production process IAO:mentioned by SOME action production plan specification

As previously stated, a design plan concretizes a design plan specification and is realized in a

conceptual design process, whose procedure is given in the action design plan specification. Similarly, a construction structure plan concretizes a construction structure plan specification and is realized in a construction structure process. In addition to that, a production plan concretizes a production plan specification and is realized in a production process (Figure 3). In the BFO-conformant parlance, design plan RO:concretizes SOME design plan specification conceptual design process BFO:realizes SOME design plan construction structure plan RO:concretizes

SOME construction structure plan specification construction structure process BFO:realizes SOME construction structure plan production plan RO:concretizes SOME production plan specification production process BFO:realizes SOME production plan

Pahl et al. [3] illustrate the engineering product development process in four phases, and each

phase uses the outcome of the previous phase, except the first one. The fourth and final phase, detail design (D4) , specifies the production process, and its output is the production plan, which is subsequently realized as a production process whose outcome is the product itself (Figure 3).

As each plan is to be realized in some process, and each process has some output, here comes the output specifications of the engineering product development process:

construction structure plan OBI:is specified output of SOME conceptual design process production plan OBI:is specified output of SOME construction structure process

Hitherto, we have defined the main classes for the product development process. The

conceptual design phase (D2) in Pahl et al. [ 3 ] follows the clarification of the task and setting up a requirement list. Thus, conceptual design process has such a list as an input. requirement list subClassOf IAO:information content entity requirement list OBI:is specified output of SOME conceptual design process The first step in the conceptual design is the process of identification of essential problems (C1) on the basis of the requirement list. The goal of this step is to understand what needs to be achieved before diving into potential solutions, which also opens the door for innovations. Such an identification process, then, requires an analysis of the requirement list from the task clarification: identification of essential problems subClassOf OBI:planned process identification of essential problems BFO:occurrent part of

SOME conceptual design process requirement list OBI:is specified input of SOME identification of essential problems

The overall function, part of the goal within the design process, is the function of the intended product, if it is realized. In (C1), on the other hand, the overall task is abstracted from the design goals, and accordingly, the overall function is stripped from its bearer. Thus, in the conceptual design phase, functions, and by extension, subfunctions, exist as parts of design plan, not as dependents to some bearers. In the process of establishment of functional structures (C2), the overall function is further analysed into subfunctions. This analysis is the task of the process of functional analysis (C2.1), which yields a hierarchy of functions: establishment of functional structures subClassOf OBI:planned process establishment of functional structures BFO:occurrent part of

SOME conceptual design process functional analysis subClassOf OBI:planned process functional analysis BFO:occurrent part of SOME establishment of functional structures

At the end of the functional analysis, according to Pahl et al. [3], the designer gets the functional structure specification, which outlines the hierarchy of functions and subfunctions. This structure helps designers identify the working principles capable of fulfilling each function.

functional structure specification subClassOf IAO:information content entity functional structure specification OBI:is specified output of SOME functional analysis The next step is the process of identification of working principles (C3). This process aligns each item of the functional structure specification to a collection of working principles. Since a single function can be fulfilled by multiple working principles, designers must select among them, which is conveyed in the following process, selection of working principles (C4). The result of the former process is a table of working principles, where each function is linked to one or more candidate principles. The table is used during the latter process.

identification of working principles subClassOf OBI:planned process identification of working principles BFO:occurrent part of

SOME conceptual design process

table of working principles subClassOf IAO:information content entity table of working principles OBI:is specified output of

SOME identification of working principles selection of working principles subClassOf OBI:planned process

selection of working principles BFO:occurrent part of SOME conceptual design process table of working principles OBI:is specified input of

SOME selection of working principles

combination of working principles subClassOf OBI:planned process combination of working principles BFO:occurrent part of

SOME conceptual design process

Different combinations of working principles can be chosen. In order to meet the needs in the requirement list, designers must choose the optimal combination. The output of the previous step is a list of possible combinations. The process of combination of the working structure (C5) includes selecting specific working principles from the collection of alternatives for each function and subfunction. The outcome of these processes, then, is a representation of the working structure:

list of possible combinations of working principles subClassOf IAO:information content entity list of possible combinations of working principles OBI:is specified input of

SOME combination of working principles

list of possible combinations of working principles OBI:is specified output of

SOME selection of working principles

representation of working structure subClassOf IAO:information content entity representation of working structure OBI:is specified output of

SOME combination of working principles

The requirement list informs the construction parameters, which are the physical and technical characteristics needed to implement each working principle in a concrete design. In the process of addition of construction parameters (C6), these characteristics are specified to enable the realization of the chosen working principles. The result is a list of such parameters, which is later used for constructing a table of correlation of evaluation criteria and parameters in an evaluation chart in the production process to assign specific values.

addition of construction parameters subClassOf OBI:planned process addition of construction parameters BFO:occurrent part of

SOME conceptual design process

requirement list OBI:is specified input of SOME addition of construction parameters list of construction parameters subClassOf IAO:information content entity list of construction parameters OBI:is specified output of

SOME addition of construction parameters list of construction parameters OBI:is specified input of SOME production process

5. Discussion and Conclusion

In this paper, we presented an OBO Foundry conformant representation of the conceptual design phase of the product development process in engineering. Doing so, we heavily used central classes from the OBI and IAO ontologies. Our suggestion also has implications for the ontology of technical functions. Officially, design functions in engineering are considered to be instances of BFO:function, which comprises both technical and biological functions. In our suggestion in this paper, however, we do not use this top-level class but rather detail the context of function ascriptions during the design process. According to our analysis, a technical function is not only a realizable entity that inheres in a technical artefact but is also grounded in a plan specification during the conceptual design phase. So, a technical function pre-exists the technical artefact as the intended goals specified in the product development process.

This work serves as proof of concept that the phases of the product development process, with

a focus on the conceptual design phase, can be represented ontologically. Thus, future work will involve evaluating the representation and the proposed axioms. It will also include a rigid representation of practical scenarios and testing several use cases both within and beyond the

Pahl and Beitz framework. This will allow us to identify which phases of the product development process may have no instances and whether alternative phases are needed for biomimetic use cases outside the Pahl and Beitz framework, and validate our axioms accordingly.

Acknowledgements

Research for this paper has been conducted under the auspices of the project “Learning from

Nature” funded by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation)

(nr. 492191929). Part of the work of Ludger Jansen on this paper has been conducted during a research stay funded by the DFG (nr. 449836922) at the Centre for Advanced Study “Access to cultural goods in digital change: art historical, curatorial, and ethical aspects” (KFG 33) at the

University of Münster. We thank Manfred Drack (Tübingen) for inspiring discussions and the anonymous reviewers for helpful feedback.

Declaration on Generative AI

The authors have not employed any Generative AI tools.

References

[1] J.P.S. Piest , V.B. J. de Oliviera , P. de A. Silva , M. R. da C. Junior , M.J. van Sinderen , A domain reference ontology for design science research knowledge bases, in: Proceedings of the Joint Ontology Workshops (JOWO). Episode X: The Tukker Zomer of Ontology, and satellite events co-located with the 14th International Conference on Formal Ontology in Information Systems (FOIS 2024 ). https://ceur-ws. org/ Vol- 3882 /showcase-3.pdf.

[2] N. Guarino , E.M. Sanfilippo , Characterizing IOF Terms with the DOLCE and UFO Ontologies , in: 10th International Workshop on Formal Ontologies Meet Industry 2019 . https://ceur-ws. org/ Vol- 2518 /paper-FOMI3.pdf.

[3] G. Pahl , W. Beitz , J. Feldhusen J , K.H. Grote , Engineering Design: A Systematic Approach . 3rd. ed. London: Springer London, 2007 . doi: 10 .1007/978-1- 84628 -319-2.

[4] M.M. Ali , R. Rai , J.N. Otte , B. Smith , A product life cycle ontology for additive manufacturing , Computers in Industry, 2019 , 105 : 191 - 203 . doi: 10 .1016/j.compind. 2018 . 12 .007.

[5] J.N. Otte , D. Kiritsi , M.M Ali , R. Yang , B. Zhang , R. Rudnicki , R. Rai , B. Smith , An ontological approach to representing the product life cycle , Applied Ontology , 2019 , 14 ( 2 ): 179 - 197 . doi: 10 .3233/AO-190210.

[6] L. Zhang , A. Olsen , A. Lobov , An ontology-based KBE application for supply chain sustainability assessment , Resources, Environment and Sustainability , 2022 , 10 : 100086 . doi: 10 .1016/j.resenv. 2022 . 100086 .

[7] C.E. Catalano , E. Camossi, R. Ferrandes R , V. Cheutet, N. Sevilmis , A product design ontology for enhancing shape processing in design workflows , Journal of Intelligent Manufacturing , 2009 , 20 : 553 - 567 . doi: 10 .1007/s10845-008-0151-z.

[8] A. Petrovan , M. Banica , Ontological Approach for the Conceptual Development of Products , in: IOP Conference Series: Materials Science and Engineering, 2020 , 749 : 012022 . doi: 10 .1088/ 1757 -899X/749/1/012022.

[9] S.C. Brandt , J. Morbach , M. Miatidis , M. Theißen , M. Jarke , W. Marquardt , An ontologybased approach to knowledge management in design processes , Computers & Chemical Engineering , 2008 , 32 ( 1-2 ): 320 - 42 . doi: 10 .1016/j.compchemeng. 2007 . 04 .013.

[10] S.K. Sim , A.H.B. Duffy , Towards an ontology of generic engineering design activities . Research in Engineering Design, 2003 , 14 : 200 - 223 . doi: 10 .1007/s00163-003-0037-1.

[11] S. Ahmed , S. Kim , K.M. Wallace , A Methodology for Creating Ontologies for Engineering Design , Journal of Computing and Information Science in Engineering , 2006 , 7 ( 2 ): 132 - 140 . doi: 10 .1115/1.2720879.

[12] S. Green , D. Southee , J. Boult , Towards a design process ontology . The Design Journal , 2014 , 17 ( 4 ): 515 - 37 . doi: 10 .2752/175630614X14056185480032.

[13] C.C. Trumbach , C. McKesson , P. Ghandehari , L. DeCan, O. Eslinger , Innovation and design process ontology , in: T.U. Daim, D. Chiavetta , A.L. Porter (eds.) Anticipating Future Innovation Pathways Through Large Data Analysis . Cham: Springer International Publishing, 2016 , pp. 133 - 151 . doi: 10 .1007/978-3- 319 -39056- 7 _ 8 .

[14] D. Yargan , L. Jansen, Building a biomimetics core ontology using OBO foundry principles , in: Proceedings of the Joint Ontology Workshops (JOWO) . Episode XI: The Sicilian Summer under the Etna, co-located with the 15th International Conference on Formal Ontology in Information Systems (FOIS 2025 ), September 8-9 , 2025 , Catania, Italy. https://ceur-ws. org.

[15] Yargan D , Jansen L. Terminological Resources for Biologically Inspired Design and Biomimetics: Evaluation of the Potential for Ontology Reuse . Biomimetics 2025 ; 10 : 39 . doi: 10 .3390/biomimetics10010039.

[16] A. Bandrowski , R. Brinkman , M. Brochhausen , M.H. Brush , B. Bug , M.C. Chibucos , et al. The ontology for biomedical investigations , PLOS ONE , 2016 , 29 ; 11 ( 4 ):e0154556. doi: 10 .1371/journal.pone. 0154556 .

[17] J.N. Otte , J. Beverley , A. Ruttenberg , BFO: Basic Formal Ontology. Applied Ontology . 2022 ; 17 ( 1 ): 17 - 43 . doi: 10 .3233/AO-220262.

[18] Z. Xiang , M. Courtot , R.R Brinkman , A. Ruttenberg , Y. He, OntoFox: web-based support for ontology reuse . BMC Res , 2010 , 3 : 175 . doi: 10 .1186/ 1756 -0500-3-175.

[19] M. Courtot , F. Gibson , A. Lister , J. Malone , D. Schober , R. Brinkman , A. Ruttenberg , MIREOT: the Minimum Information to Reference an External Ontology Term , Nature Precedings , 2009 . doi: 10 .1038/npre. 2009 . 3576 .1.