Towards a formal ontology of engineering functions,behaviours,and capabilities

Abstract

In both applied ontology and engineering, functionality is a well-researched topic, since it is through teleological causal reasoning that domain experts build mental models of engineering systems, giving birth to functions. These mental models are important throughout the whole lifecycle of any product, being used from the design phase up to diagnosis activities. Though a vast amount of work to model functions has already been carried out, the literature has not settled on a shared and well-defined approach due to the variety of concepts involved and the modeling tasks that functional descriptions should satisfy. The work in this paper posits the basis and makes some crucial steps towards a rich ontological description of functions and related concepts, such as behaviour, capability, and capacity. A conceptual analysis of such notions is carried out using the top-level ontology DOLCE as a framework, and the ensuing logical theory is formally described in first-order logic and OWL, showing how ontological concepts can model major aspects of engineering products in applications. In particular, it is shown how functions can be distinguished from the implementation methods to realize them, how one can differentiate between capabilities and capacities of a product, and how these are related to engineering functions.

Keywords

Ontology function behaviour capability DOLCE

1. Introduction

Functionality is a concept that has interested engineers as well as philosophers and applied ontologists. It is used whenever engineers and scientists discuss the need for and the goals of systems, both natural and artificial. For example, engineers commonly use functions in order to design [78] and diagnose devices [57], while philosophers discuss the nature of functions themselves [20].

Despite the high amount of attention given to this topic, many problems remain open [3] and even the terminology can be quite confusing: function and closely related terms such as capability, capacity and behaviour have been used with many different meanings [11,23]. Moreover, the study of functional decomposition, that is, the division of functions into sub-functions, is often addressed in the literature as a means to guide the conceptualisation, design, and maintenance of products, but is rarely formalized. By and large, functional decomposition consists in associating the product’s main function with a combination of sub-functions with the assumption that realizing these (in a certain order and with suitable coordination) is equivalent to realize the main function. This decomposition simplifies both the design process and the implementation of the functional requirements into a concrete physical system. Of course, functional decomposition is not limited to the design of engineering systems. In fact, during the teleological analysis of a system, artificial or natural, domain experts speak about functions of both the system and its parts. Therefore, one is always confronted with the problem of how functions of components contribute to functions of the system they compose, so that functional decomposition is ubiquitous. Functions are often distinguished from their realization (or manifestation). Since in engineering there exist standard ways to realize functions,1

¹
For example, the use of gearboxes made in a certain way in order to increase or reduce angular velocity, and a brushless electric motor as a way to convert electric energy to torque.

one has also to address the relationship between functions and engineering methods,2

If the method has just been introduced and has not yet reached a consolidated status in practice, we still call it an engineering method. In fact, the term engineering method refers primarily to technological principles and theories on which an implementation relies.

or solutions [78], or ‘ways of functional achievement’ [43]. Another point of discussion is the relationship between functions and behaviours, the latter being usually seen as the way a device interacts with other entities. In engineering, devices are expected to maintain their functionality over time (at least to some extent) and to manifest regular (or at least predictable) behaviours, which brings into the picture the notions of capacities and capabilities. These two are not always distinguished, as we will see, and yet are essential to understand how a device can realize a given function, and which functions can be realized by a given device.

This paper focuses on these notions and their relationships from an ontological and an engineering viewpoints. It builds on previous research, especially on modeling engineering processes and resources, see [9,11,83,85], and on function definition and functional characterization [4,6,25,71], and aims to discuss what functionality and related concepts are in a formal way. The formal languages used in the paper are first-order logic [91], adopted for the general discussion of concepts and their relationships, and OWL [102] for the use case. To give a clear ontological grounding for our formalisation, we use the top-level ontology DOLCE,3

The interested reader can find a complete and in-depth presentation of DOLCE in [65] and its application in use cases in [7].

as presented in the (under development) standard ISO 21838-3,4

⁴

www.iso.org/standard/71954.html

as reference.

The objective of our work is to answer the following research questions (RQ) which are motivated by the works cited above and the literature review in Section 2:

How can the wide range of meanings carried by the term ‘function’ be ontologically differentiated and explained?

How can the functional decomposition of a system be explained and formalized?

What are capabilities and capacities, how do they relate to functionality, and what is the difference between them (if any)?

By answering these RQs, we aim to clarify and formalize within a unified framework the core functional concepts in engineering, namely, function, behaviour, capability, and capacity. In particular, we discuss the relation among functions as entities independent of any implementation, which we call ontological functions, functions that depend on the teleological analysis of a given system, that is, functions contextualized to a system, that we call systemic functions (from [71]), and functions as entities related to an execution method, which we call engineering functions. Finally, ontological functions will be leveraged to propose a general distinction between capabilities and capacities of engineering artifacts, in this way we provide the necessary elements for functional attribution, i.e., to establish which device can realize a certain function.

The structure of the paper is as follows. A review of the literature about functionality that is particularly relevant for this work is presented in Section 2. Section 3 describes key concepts of DOLCE. These are exploited in Sections 4, focused on functions and behaviours, and 5, focused on capabilities and capacities, leading to an integrated view of capabilities, capacities, behaviours, functions, and, very briefly, affordances. The sections proposes also a formal interpretation of ontological and engineering functions in first-order logic, and give a preliminary characterisation of capabilities and capacities. We showcase and evaluate a preliminary ontology in the OWL language in Section 6, before drawing our conclusions in Section 7.

2. Literature review

Due to strong practical interests, a vast literature about functionality has been developed within engineering. We limit ourselves to a brief review. The reader interested in a more in depth analysis can refer to other works like [23] in engineering and [3] in applied ontology.

Fundamental contributions on functionality in engineering are, for example, the work of De Kleer [21,22], which outlines foundational principles such as the locality of functions (functions of a component should refer only to neighboring entities) and the ‘no function in structure’ principle (structural models should not contain teleological information); and the work of Pahl and Beitz [78], which describes functions as black-box transformations applied to input flows, divides functions based on the property of the flow acted upon (e.g., quantity, type, position, etc.), and discusses function decomposition (that is, how to achieve a given function through a structure of adequate sub-functions).

In [78] Pahl and Beitz explain also how designers can start from a generic function and proceed to develop products that can realize it via solutions based on different physical principles. They cite many design catalogues, which list and classify solutions along different criteria, see, e.g., [82]. In the context of design catalogues, functions and solutions exist along the same abstract-concrete axis, and differ by the ‘degree of embodiment’. Thereby, the most abstract functions, called ‘generally valid functions’, are the most useful criteria to classify solutions in a product-independent way.

The definition of function as (intended) action on flows is the most common in the engineering. For example, Chandrasekaran et al. [16] speak of ‘intended input-output relations’. Many vocabularies were developed with the aim to standardize the terminology of such actions. The proposed vocabularies range from Keuneke’s short four terms list (toMake, toMaintain, toPrevent, and toControl) [42], to larger vocabularies built using complex algorithms, like in the work of Kitamura and colleagues [49]. A common example is Stone and Wood’s Functional Basis [37,94], which gives terms for actions and flows on a three-levels taxonomy described in natural language. The literature about the use of such vocabularies has not settled yet and, currently, different lines of research are being pursued, such as behavioural simulation of a system from the functional model [56] or formal description and automatic construction of the functional model itself [30,55].

It is generally recognized that functionality depends on the purpose of an agent, leading to discuss notions like the designer’s intent or the ‘design rationale’ [16,46]. Thus, functions are not objective, at least not completely. Then, it is natural to wonder what in a function is fully objective. Behaviour, intended as what a device does, as determined by physical laws, is usually the answer.

The term behaviour is also used broadly without an universally shared definition. This generates ambiguities and some authors tried to classify the multiple uses of this term in engineering literature. For instance, Kitamura et al. [46] determine four types of device behaviour,5

⁵
They explicitly exclude static behaviours such as supporting, though.

depending on whether the device changes the state of another device, its own state, or the state of some other entity.6

⁶

The entities on which a device acts are called operands.

Within the second behaviour type two additional cases are distinguished: the operand can either stay in the same position or ‘move’ from the input to the output ports (the latter case is called B1 behaviour, for example, ‘a motor converts electrical energy to torque’ and ‘the signal intensity is increased by the amplifier’ are examples of B1 behaviour, while ‘the temperature in the room is increased by the oven’ is not a B1 behaviour, neither is ‘the turbine is rotating’). For another view, Chandrasekaran and Josephson classify six types of behaviours mainly depending on their time duration (instant, interval, or unspecified) and the values of the state variables during that time [17].

The link between behaviour and function generally reflects the duality between objectivity and intentionality: some authors state that behaviour is what a device does, whilst function is what a device is for [22], others focus on describing behaviour as a sequence of state changes and functions as abstractions of behaviours with a goal in mind [96]. Sasajima et al. state that function is made from behaviour plus additional teleological information called ‘functional topping’ [87,88]. Specifically, the functional topping allows, among other things, distinguishing the different functions that a device can execute (e.g. an electrical resistor could be devised for either heating the environment or for dropping the input voltage, and the functional topping in these two cases is different7

⁷

More precisely, when the resistor is used for heating, the functional topping tags as ‘Focus’ the heat flow exiting the output port, when the resistor is used for dropping the voltage, it is the electric energy output of the resistor that is tagged ‘Focus’.

). For Chandrasekaran and Josephson [17], functions are sets of intentionally selected constraints on behaviours. These constraints are seen as causal relations between devices’ states.

As we have seen, numerous modelling frameworks have been developed in order to deal with functional and behavioural representation of engineering systems (e.g., Umeda et al.’s FBS [96], Sasajima et al.’s FBRL [87], Sembugamoorthy and Chandrasekaran’s FR [89], Goel et al.’s SBF [31], Qian and Gero’s FBS [80]), and they differ on many aspects. Still, oversimplifying, one can isolate commonalities: all of them tend to see the structure of a device as a set of parts (components) together with their attributes and the relations between them. Then, typically, they say that a behaviour is a sequence of states of the components. The definition of function is more complex but, again roughly speaking, a function is used as a label for a subset of behaviours. Finally, they mostly recognize a dependence of functions on behaviours, and of behaviours on the structure. There are, of course, key differences. For example, (functional) behaviour in Chandrasekaran’s FR scheme refers to a causal process while behaviour in Gero’s FBS representation pertains to the properties of a structural component. Or the fact that Gero and Chandrasekaran explicitly allow for decomposition of functions into behaviours, while in Sasajima’s approach a decomposition of functions into behaviours is forbidden and functions decompose only into other functions.

Among the previous frameworks, we find particularly interesting the development of FBRL. This is because, while for engineers functions usually are either already-assigned functional requirements (things that a product must be able to do) or are not distinguished by implementation methods, the authors of FBRL started, in our opinion, to study functions as entities by themselves. For example, at least from [44], they studied relations between functions themselves (called ‘meta-functions’), and analyzed the properties of functions, building complex taxonomies of functional concepts. This is important for our work, since it is one clear example of what we call ontological functions, while the engineering functions are the ones that, as in Pahl and Beitz’s work, exist only to be implemented by some method in an application context.

Most of the frameworks used for modelling functions come from the engineering community and tend not to be grounded in, nor aligned with, ontological theories. The presence of explicit connections between these framework and ontological theories would be quite beneficial, especially because of the large number of such engineering systems and of the importance of clarifying the use of the terminology. Moreover, engineers often do not make use of formal languages such as first-order logic or OWL,8

⁸

There is, of course, also the fact that OWL was first published in 2004, while many works of functional modelling are older.

instead preferring informal descriptions in natural language or pseudo-code.9

⁹

There are exceptions, e.g. Kitamura et al. [43] and Yang et al. [103] showcase an implementation of an industrially deployed version of FBRL, called SOFAST, and an OWL and SWRL formalisation of the Functional Basis, respectively.

In addition, some topics such as the link between function and malfunction, the difference between function and behaviour, or the methodology with which to carry out the decomposition of a function have been tackled differently by these systems but, overall, it does not seem that a reliable and shared view is emerging.

Despite the utility of an ontological analysis of these topics, the attempts carried out until now are limited. A few research works have formalized part of the FR system [4], started a formalisation of the Functional Basis vocabulary (and the conceptualisation it is based on) with the upper ontology DOLCE [5], compared the Functional Basis either with the FR system [25] or with both FR and FBRL [50], and the function decomposition relation has been analyzed with ontological techniques [99,100]. Additionally, applied ontology has influenced engineering literature, as shown by the description of functions as roles played by behaviours [17,43,71], or the classification of behaviours as occurrents10

¹⁰

An ontological category similar to DOLCE’s perdurants, see Section 3.

[43].

Still, no shared reference ontology of functions exists, and top-level ontologies do not explore theories of functions as understood in engineering. For example, DOLCE makes no mention of function within its specification [65]. The last version of YAMATO classifies functions as roles and behaviours as processes11

¹¹

Note that even if processes exist as a category also in DOLCE, in that TLO behaviours are still more similar to events and not processes. This is because the process category of YAMATO and the one of DOLCE are different: in YAMATO processes wholly exist at each point in time, while in DOLCE they are a special kind of events. YAMATO and DOLCE are instead aligned on the notion of events.

caused by an unintentional actor. BFO defines functions as dispositions that exist in virtue of their bearer’s physical make-up, and such that the physical make-up came into being through intentional design (in the case of engineering). Other than that, BFO does not commit to an axiomatisation, at least not within the axiomatisation of BFO currently present in GitHub.12

¹²

BFO 2020: https://github.com/BFO-ontology/BFO-2020.

GFO too states that functions can be realized by other entities, but makes no mention of dispositions and, instead, calls functions ‘intentional entities’ [36]. The recent development of ISO 15926 [52] adopts BFO view of functions as dispositions realized in particular processes.

In truth, despite the relatively small space that functions occupy in these upper-level ontologies, their authors have been discussing functionality at length in various research papers. For example, some of the DOLCE’s authors suggest seeing functions as particular types of events, while they see behaviours as ‘qualifications of the participation relation’ in that behaviours explain the specific way a device participates in a specific event [5,11,25]. On the other hand, the authors of YAMATO deepen their view of function in a series of additional papers, among them [43,48,70,71], in which they motivate and detail their claim that functions are roles played by behaviours, the latter being processes of a certain type (notice that YAMATO and FBRL were developed by the same research group).

The view of GFO’s authors has some similarities with the one of FBRL, in that functions despite not being roles themselves, are linked to ‘functional items’, which are roles played by the entities realizing the function. Functions themselves are complex entities, composed of a functional item, a label to identify them, and descriptions of the initial and final states corresponding to the function execution, called ‘requirements’ and ‘goals’, respectively [13,14]. The typical example is the function ‘to transport oxygen’, which is linked to the functional item ‘oxygen transporter’ which can be played by a red blood cell. Then, a requirement for the realisation of the function is the presence of oxygen in the red blood cell environment and the goal is the presence of oxygen in the body cells that need it for cellular respiration. Another similarity with the FBRL is the development of teleological relations between functions similar to meta-functions. For example, [13] mentions the relations ‘support’, ‘enable’, and ‘prevent’, depending on the fact that the goal of the first function fulfills partially, completely, or is incompatible with the requirement of the second function (cfr. with [44], which also uses the term ‘enable’ and ‘prevent’, among others).

Coming to BFO, the view of functions as special dispositions was expanded and defended by its authors in [2,93], and criticized by other philosophers, e.g., Röhl and Jansen [40,81], arguing that functions and dispositions must be disjoint, though related, categories. More specifically, in BFO functions are defined as follows [93]:

“f is a disposition & f exists in virtue of its bearer’s physical make-up & this physical make-up is something that this bearer possesses because it came into being, either through evolution (in the case of natural biological entities) or through intentional design (in the case of artifacts), in order to realize processes of a certain sort.”

Since all dispositions in BFO cause the physical make-up of their bearer to change when they cease to exist [93], the same holds for functions as well. Also, Röhl and Jansen insist that functions are “externally grounded”. Moreover, a major point of disagreement concerns malfunctions, in that Jansen argues that malfunctioning entities are entities that have a function, but lack the means to realize it, for example because they have lost the required dispositions; while BFO’s authors maintain that when an entity malfunctions it loses its function, partially or completely, and is recognized as an entity of its kind only because of its history, if at all (e.g., a cancerous lung is not a lung). Notice that in both of these positions functions and roles are assumed to be disjoint subclasses of realizable entities, on the ground that roles are accidental for their players, while functions are essential for their players.

As we have seen, the meaning of function is ambiguous even within the ontology community. Moreover, it is generally not considered a top-level concept, and thus it is marginally covered by top-level ontologies. Unfortunately, to our knowledge, the ontology community has not produced a shared middle or domain-level ontology dealing with functions.13

¹³

An initial taxonomy of an ontology of functions in this sense, which is resumed and extended in this paper, was proposed by Borgo et al. in [11] and [6].

Given the current situation, an ontological analysis clarifying the domain of functionality would be quite useful. This paper aims to provide an initial step in the direction of developing a systemic ontological treatment of functionality, focusing in particular on the engineering domain. It might be true that the ambiguity of function terminology is both necessary and rational for engineers [98]. Still, we maintain that formalisation is needed for interoperability and to show differences between the possible approaches. Moreover, it is useful, if not necessary, to develop applications that rely on functional reasoning.

In conclusion of this section, we briefly mention other engineering concepts whose ontological status is quite complex: capabilities, capacities, and affordances. Capacities and, especially, capabilities are used in resource modelling [39,41,85,86,92]. In addition, terminological problems are present also for these two concepts, which are rarely formalized [11,84]. When distinguished, capabilities and capacities are separated along a qualitative-quantitative axis, for example ISO 15531-31 [39] states that ‘Capacity is strictly a quantitative concept’ while ‘Capability is essentially a functional and qualitative concept’, and exemplify capacity with product throughput and define capability as ‘the quality of being able to perform a given activity’. The same standard advises against reducing capacities as characteristics of capabilities and forbids the opposite (in contradiction to [92], where a ‘Capacity is a Capability expressed in terms of amount of production’). In addition, the concept of capability is sometimes used interchangeably with functionality: for example, the standard VDI 2860 [97] lists a vocabulary of actions that machines can execute when manipulating products (e.g. ‘guide’, ‘rotate’, etc.) and calls them ‘functions’. At the same time, this very standard is quoted in the literature with the aim of establishing standard-based capability taxonomies [53,54]. In any case, in this paper we will try to formalize, in a preliminary way, some intuitions that transpire from the literature on resource modelling, such as the asymmetry between capacities and capabilities, the close link (but not identity) between capabilities and functionality, qualitative vs quantitative aspects, and the idea of capabilities as qualities of being able to do something.

The notion of affordance is another source of conceptual confusion: affordances were originally introduced by [29], and popularized in engineering design by Maier and Fadel in a series of works ([61,62], among others) as a paradigm-shift from a function-based design, towards an interaction-based design, characterized by the focus on all the possible ways a user can interact with a product, included those unintended by the designer and not strictly relevant for the product function. Briefly, affordances are “what it [the environment] offers the animal, what it provides or furnishes, either for good or ill” [29]. That is, they are potential behaviours that the environment, or a part thereof, allows an agent to do. In engineering, they are often defined as the set of all the behaviours that an artifact enables a user to do [12], but this is far from being a universally shared definition. The original example of Gibson was that a flat surface affords footing to an animal, while other examples could be a pool full of water, which affords a person to swim, or a briefcase, which, affords a person to be grabbed; so that one could say that ‘swimmability’ and ‘grabbability’ are affordances of the pool and the briefcase, respectively. Unsurprisingly, an unsettled debate exists in the disciplines that make use of the concept of affordances, about their meaning [12], up to the point that some authors called for their abandonment [73]. In this paper, we do not carry out an ontological analysis of affordances (see [76] for an approach compatible with ours). We mention them as an important engineering concept that is related to functions [12] and, at the end of Section 4, we point out a few similarities affordances share with capabilities.

3. An (enriched) subset of the DOLCE ontology

As stated in the introduction, we will use DOLCE as top-level ontology. The reasons we chose DOLCE are, at least, the following:

DOLCE is a well-known upper ontology that has been tested in many applications and recently became a standard (part of the ISO 21838).

DOLCE has remained stable for 20 years showing reliability (all other upper-ontologies have been reworked extensively often along the lines of DOLCE).

DOLCE is a descriptive ontology that “aims at capturing the ontological categories underlying natural language and human commonsense” [65]. For this reason, theories formulated using DOLCE tend to be easy(er) to use and understand.

We agree with Jansen and Röhl [40,81] on the external grounding of functions and the relation of functions with malfunctions. Therefore, we cannot use ontologies, such as BFO, which make incompatible ontological commitments with this view.

In this section we introduce the fragment of the DOLCE ontology [7,65] that is needed for this work.14

¹⁴
See Fig. 1 for a complete taxonomy.

In particular, we cover the following classes which will be needed to model functions and related concepts: qualities, perdurants, and roles. We anticipate that we will argue in favor of subsuming capabilities and capacities into qualities, behaviours into perdurants (events), and (a certain kind of) functions into roles. The links among these concepts will be, roughly, as follows: role-functions classify behaviours, capabilities require functions to be defined and existentially depend on capacities, the latter being relational qualities of artifacts.

Fig. 1.

DOLCE taxonomy, taken from [7].

DOLCE qualities were inspired by the trope theory [15] but differ from tropes in important ways. Qualities, for example the weight of a car and the color of a flower, are used for representing individual properties, i.e., specific properties of the individual objects in which they inhere. Thus, the weight property of a given car is specific to that car, which is called the bearer of that quality. Each quality is itself an individual and ‘belongs’ to its bearer. Consider a number of cars, say five. The colors of these five cars are five color qualities, one for each car, even though the five cars could be indistinguishable regarding their color. Differently than tropes, qualities are associated to values and these can change in time. For example, the color quality of a flower can change its value as time passes: red in summer and brown in fall. Indeed, values of qualities, called quales, are distinguished from qualities themselves. In this way, the assignment of values to qualities is flexible and follows the schema object-quality-quale (or bearer-individual quality-value). In DOLCE, qualities form the class $Q$ (whose predicate is written $Q (\cdot)$ ) and the inherence relation is ‘quality-of’ (written $qt (\cdot, \cdot)$ ). A temporal quale relation associates a quality with some value which, as said, may be different at different times, and is written $ql (\cdot, \cdot, \cdot)$ .

We introduce a further distinction, not present in DOLCE, between intrinsic and relational (or extrinsic15

¹⁵

Note that the terms ‘relational’ and ‘extrinsic’ come from different research areas and are sometimes used with different meanings.

) qualities [64]. Standard examples of intrinsic qualities are mass, length, and shape; of relational qualities are weight (which is relative to a gravitational field), the personal record for a marathon (which is relative to the social concept of marathon), and the distance of an object from another object (which requires the existence of both objects). Briefly, relational qualities are qualities of an object per se that depend on other things like another object, the context or the environment. To clarify our intuition we illustrate some of the previous examples: the distance of the Moon from the Earth, seen as a property of the Moon, cannot be thought of without considering the Earth, so we say that it is a relational quality of the Moon (similarly, for the distance of the Earth from the Moon). In contrast, if a certain brick has a given tensile strength, this fact does not depend on other entities, so that tensile strength is an example of intrinsic quality;16

¹⁶

Of course, one needs other entities to measure the tensile strength value, but note that this dependence is relative to establishing the value. The tensile strength exists independently of how one may measure it.

similarly, other mechanical or chemical qualities, for example ductility or the structure of the atomic lattice in crystals, can be considered intrinsic. Another example is the difference between weight and mass of a body: the mass is intrinsic while the weight also depends on the position of the body in a gravitational field, e.g., if the body is on the Earth or on the Moon, which makes the latter quality relational. A more technical example is the voltage at a point of a component, which, since it is a potential, requires a second point used as reference (the ground of the electrical circuit) in order to be meaningful. Informally speaking, capacities can be understood as having a relational nature, which explains our interest in the intrinsic/relational distinction across qualities. For, if we speak about the capacity of a device, say the capacity of a machine to process a certain number of items in a given time, then such capacity always refers to another entity, in this case the (prototypical) item. Analogously, in [80], Qian and Gero stated that there are different types of ‘behavioural variables’: structural, as the area of a room or the diameter of a water tap, and exogenous, as the water flow through a water tap. In the latter example, the water flow is an exogenous variable because ‘water is not part of the water tap design, it is only related to the design’, so that we could argue water is an additional entity required by the water flow quality of the tap, suggesting that this form of exogeneity can be captured via our notion of relational quality.

In the previous examples, it seems that relational qualities are those qualities that depend, in some way, on an entity different (we say external, see (d2)) from their bearer. Unfortunately, the exact meaning of this dependence relation changes between the different examples. In particular, in the case of capacities the dependence is ‘potential’, for a device can have the capacity to process a product, even when the product is not actually present. In contrast, in the case of relative distance the dependence is ‘actual’, for a physical object is at any time at a certain distance from another.It follows that the characterisation of relational qualities is a complex matter that goes beyond the scope of this paper.17

¹⁷

The interested reader can find a proposal on relational and intrinsic qualities in [24].

Therefore, we introduce intrinsic and relational qualities as primitive predicates that partition the class DOLCE-qualities:

$relationalQt (x) ⟹ Q (x)$

$intrinsicQt (x) ⟺ (Q (x) \land \neg relationalQt (x))$

Turning now to perdurants ( $PD (\cdot)$ ), in DOLCE they are entities that are only partially present at any time they are present.18

¹⁸

Ordinary physical objects such as cars, trees, rocks, etc. are fully present at every time in which they exist.

For example, a chemical process, the lifting of a load, and a sitting action are only partially present at each instant at which they happen. Indeed, the initial part of a chemical process is not present when the process reached the midway point, and vice versa. DOLCE uses three mereological properties to distinguish perdurants: cumulativity, homeomericity, and atomicity. Cumulativity holds if the sum of two instances of a type has the same type, that is, if the type is closed under mereological sum. Consider, for example, ‘walking’: if we consider two walking activities, then the activity that comprises both is still an activity of type ‘walking’. Cumulative perdurants19

¹⁹

More precisely, instances of a cumulative type perdurant.

are called stative (

STV (\cdot)

), while the ones that are never cumulative are called eventive. Homeomericity holds for a perdurant type if any parts of its instances are instances themselves. This is the case of, e.g, ‘sitting’, since portions of a sitting action are still sitting actions. Stative homeomeric perdurants are called states (

ST (\cdot)

), while the ones that are stative but have parts of different type are called processes(

PRO (\cdot)

). Walking itself is an example of process in DOLCE: walking requires at least to complete a certain leg movement, below such granularity is not a walking movement. Another example is the buzzing of a clapper (or buzzer): the clapper alternates between two states when clapping (opened/closed circuit), and neither state is per se of buzzing type. In DOLCE the temporal relationship between a perdurant and the object participating in it is called participation, written

PC (\cdot, \cdot, \cdot)

: in the previous example a participant of the buzzing is the clapper.

Coming to roles, they were not covered in DOLCE originally. They have been introduced later as an extension [66], and are now part of the expanded taxonomy [7]. Roles are antirigid and dependent (aka founded) classes [34,35,66]. A class is antirigid whenever its instances are not necessarily so, and is dependent if all of its instances (existentially) depend on some external entity, often called context. For example, a certain person can be a student, but no person is necessarily a student. Actually, we expect that a student ceases to be such after some time. In contrast, any person is necessarily a person, and is so independently of other external entities. An ontological class (existentially) depends on, or is founded on, another if, whenever an instance of the first class is present, a corresponding instance of the second is present too. For example, for every citizen there is a country, so that someone’s citizenship depends on the country. Actually, in this paper, we will be more precise and distinguish between different kinds of dependence and founding, but the basic idea is still captured by the citizen-country example. Additionally, some authors divide roles depending on the type of their context, for example [59] distinguishes relational, processual, and social roles. The classification depends on whether the context is a relation, a process, or a social object. In DOLCE, roles ( $RL (\cdot)$ ) are reified and considered as concepts ( $CN (\cdot)$ ), which themselves are a class subsumed by the class of non-agentive social objects ( $NASO (\cdot)$ ):

$RL (x) ⟹ CN (x)$

“a role is a concept”

$CN (x) ⟹ NASO (x)$

“a concept is a non-agentive social object”

In this paper, the fact that roles are founded is particularly important, thus, we give the following formalisation, where

CF (\cdot, \cdot, \cdot)

(‘classified-by’, also called ‘play-as’, if the first argument is a role) is the classification relation between a concept and its instances at a certain time, cf. [66]. In the formalisation we use some other relations taken from DOLCE, namely: constitution,

K (\cdot, \cdot, \cdot)

, which is the relation holding between some amount of matter and an object when the latter is made of the first (e.g., a statue and the amount of clay it is made of);

O (\cdot, \cdot, \cdot)

, which is the usual temporal overlap relation (e.g., two semi-detached houses overlap because of the wall they share during the time they both exist); and

PRE (\cdot, \cdot)

, which is the relation “being present (exist) at time”.

$externalTo (x, y) ⟺ \neg (qt (x, y) \lor qt (y, x) \lor \exists t (K (x, y, t)) \lor \exists t (O (x, y, t)))$

“x is external to y if and only if x is neither a quality of y, nor y of x, nor x is one of y’s constituents (at any time), nor x and y have parts in common20

²⁰

Substrata, parts, and qualities may not cover all possibilities especially if a different top-level ontology were used.

(at any time)”

$dependsOn (x, y) ⟺ (\exists t (PRE (x, t)) \land \forall t (PRE (x, t) ⟹ PRE (y, t)))$

“x existentially depends on y if and only if x exists at some time and at any time when x exists so does y”21

²¹

The existential quantifier is a technicality: without it an entity that is never present would depend on all entities. Similarly, existential quantifiers are introduced in axioms having a similar structure to this one.

$founded (x, y) ⟺ (dependsOn (x, y) \land externalTo (x, y))$

“x is founded on y if and only if x existentially depends on y and y is external to x”

Further, we specialize the founding relationship to concepts and their instances as follows:

${founded}_{Inst} (x, y) ⟺ (CN (x) \land CN (y) \land \exists z, t (CF (z, x, t)) \land \forall z, t (CF (z, x, t) ⟹ \exists w (externalTo (z, w) \land CF (w, y, t))))$

“the concept x is instantiation-founded on the concept y if and only if, whenever z is a given entity that plays as x, there is also an external entity w that is an instance of y”

$RL (x) ⟹ \exists y {founded}_{Inst} (x, y)$

“if x is a role, then there is a y on which it is instantiation-founded”

For example, the role of ‘husband’ (x) in (d5) is instantiation-founded on the concept of ‘marriage’ (y), since every time a person (z) is a husband there is an individual marriage (w) between that person and another person, which is external to the ‘husband’ role: this means that there cannot be a husband if there is no marriage.

We also need to capture a different kind of founding relation, that we call definition-founding ( ${founded}_{Def} (\cdot, \cdot)$ ). We do not formalize this relation as it requires discussing how to formally define roles, a topic beyond our concerns in this paper. We will use it with the following informal interpretation: “x is definition-founded on some entity y if and only if y is used to define x”. For example, if a doctor is defined as a person who treats sick people, then the doctor-role is definition-founded on the sick-person concept. Note that instantiation-founding and definition-founding need not coincide. A person is a doctor even though, at a certain time, she is not treating any sick person: the doctor-role is not instantiation-founded on someone being in a sick state.

Finally, since roles, as well as concepts, can be seen as reified classes, there exists a specialisation relation between roles, which we write as $SP (\cdot, \cdot)$ :

$SP (x, y) ⟺ (CN (x) \land CN (y) \land \exists z, t (CF (z, x, t)) \land \forall z, t (CF (z, x, t) ⟹ CF (z, y, t)))$

“A concept x specializes a concept y if and only if all instances of x are also instances of y”

For example, the role of the Italian Prime Minister specializes the role of Prime Minister. This notion of specialisation is admittedly weak. One would like to add a modal characterisation: definition (d6) should hold in all possible worlds. This problem applies to other definitions we introduce in this paper and is not ontological but related to the limitations of first-order logic. Without discussing logical technicalities, in this paper we will make use of these characterisations assuming that, in suitable systems, e.g. first-order modal logic, a suitable formula is substituted.

4. Modelling behaviours and functions in DOLCE

In this section we propose a framework to characterize how behaviour and function of engineering artifacts can be understood to make sense of the distinctions used by engineers in different areas, from engineering design to manufacturing and maintenance, from process planning and product planning to early system design planning. Within the following section, we will expand this view to capability and capacity.

In the literature, many terms are used to refer to engineering systems and devices such as part, component, tool, machine, (technical) artifact, functional object etc. We use technical artifact22

²²
See [8] for a more in-depth discussion of technical artifacts.

to mean any physical object (see (a5)) that comes into being through an intentional technical process, such as, e.g., cars, planes, tooling machines and, more generally, devices designed to perform tasks. Also, we will use the terms ‘device’ and ‘technical artifact’ as synonyms. Additionally, we will use the term system in order to highlight the mereological structure of a complex artifact. The notion of system is complex, cannot be reduced to that of technical artifact, and its precise characterisation is an open problem (see e.g. [69]). In the paper, we take this notion as given introducing a primitive class,

System (\cdot)

. In particular, technical artifacts belong to this class. The mereology mentioned above is built as usual from the temporalized parthood relation of DOLCE,

P (\cdot, \cdot, \cdot)

. DOLCE defines also a non-temporalized parthood relation,

CP (\cdot, \cdot)

, given in (d7). Axiom (a6) and the class

POB (\cdot)

, the category of physical objects, are also taken from DOLCE.

$TechArt (x) ⟹ POB (x)$

“a technical artifact is a physical object”

$CP (x, y) ⟺ \exists t (PRE (y, t)) \land \forall t (PRE (y, t) ⟹ P (x, y, t))$

“x is constantly part of y if and only if whenever x exists, it is part of y”

$P (x, y, t) ⟹ (PRE (x, t) \land PRE (y, t))$

“if x is part of y at time t, then x and y are both present at time t”

4.1. Engineering behaviours

Engineers create an artifact to realize a certain interaction between the artifact itself and elements of the environment. The behaviour of an artifact is the way in which that artifact participates in that interaction (e.g. ‘[the car] rattled when it hit the curve’ [17]). In DOLCE one models the happening of the interaction as a perdurant. How to ontologically understand behaviour is more tricky. In the literature, the term behaviour is used with different meanings, e.g., as simplified part or description of processes like in these excerpts: ‘The causal rules that describe the values of the variables under various conditions’ [17], ‘the behaviour represents objective conceptualisation of its input-output relation as a black-box’ [43], ‘situation-independent conceptualisation of the change between input and output of the device’ [70]. In YAMATO [72] behaviours are modelled as processes with an ‘agent or an agent-like object as a doer’. Instead, in [4] Borgo et al. model them as relational qualities which characterize the specific way of participation of an object in individual events.

Here we discuss a few key ontological properties to distinguish possible definitions of behaviour. There are, in fact, at least four axes along which different meanings of behaviour can vary in the literature. First, there is what we call the occurrence-property dichotomy:

behaviour can be something that happens in time and in which the behaving entity participates, in this case it is typically referred to as a transition between states or just as (staying in) a state. Examples are provided by Goel [32], Chandrasekaran [17], Umeda [96], and YAMATO authors’ [70].

behaviour can be a quality, that is, something inhering into the behaving entity. Examples are provided by Borgo et al. [4], see also Vermaas or Gero and colleagues which talk of attributes or dispositions [27,101].

Then, there is the token-type distinction: behaviour can be a class or a concept, as for Mizoguchi in [70]. Alternatively, it can be an instance of something, or an entity relative to a specific event, as for Chandrasekaran and Josephson in [17], and for Borgo et al. in [4], respectively.

Additionally, there is the external-internal axis, that is, the behaviour of an artifact may refer only to characteristics of the artifact itself, or it may need to refer to external entities. For example, ‘the electric switch can alternate between open and closed states’ is an internal behavioural description, as it refers only to transitions between states of the artifact. In contrast, ‘the current passing through an open switch is zero, if the applied voltage stays within operating conditions’ is an external description, since, the current and the voltage are not intrinsic elements of the artifact. Some authors explicitly use behaviour with the internal meaning, e.g. Zhao et al. in [104], others with the external one, as Kitamura et al. in [47].

Finally, there is the modal axis, since behaviours can be either expected (i.e. as envisioned by engineers) or actual (i.e. what actually happens), as implied by Gero in [28] with respect to design activity (though one could use the same duality when talking of, e.g., malfunctioning). This axis includes, arguably, talks of causal laws or relations, since those could be conceptualized as changes of a system under some kind of modality, that is, changes that necessarily happen when some condition is met. We do not argue in favor of conceptualizing causal laws in this way, but, in any case, one must also take this use of behaviour into account, since it is encountered often.

In this paper, we take an engineering behaviour to be a DOLCE perdurant with a few assigned roles. The class of engineering behaviours, called just behaviours from now on, is the class of perdurants in which one can identify two ‘processual’23

²³
Note that the term ‘processual role’ refers to general perdurants, it is not limited to DOLCE processes. The terminology is taken from Loebe which introduces it relatively to the GFO approach [59].

roles in the sense of [59]: an active one, called doer, and a passive one, called operand or flow [78]. This role-based notion of behaviour is motivated by (and restricted to) the domain of functional modeling where it highlights a common engineering viewpoint. This notion complements the broader ontological view of behaviour as a relational quality between an entity and its environment, which was introduced in [4]. While the role-based view introduces behaviour as a perdurant and fits naturally with the view of ontological function that we will investigate later, the ontological notion of behaviour can be resumed to distinguish the behaviour of the doer from that of the operand, if necessary. For instance, a cutting action entails that there is something that is the subject of the action, say a saw (or the system formed by a person or machine using the saw), and the object of the action, say a beam of wood. At the same time, the saw has its own specific way to interact with that environment (to which the wood belongs), i.e., its own ontological behaviour, and so does the wood with respect to its environment (to which the saw belongs). The same holds for pumping, joining, and other behaviours described by transitive verbs.

All devices’ engineering behaviours that can be described as operations on operands have engineering behaviours as described above. Such behaviours, whose class we characterize with predicate $Behaviour (\cdot)$ , are external behaviours, since the flow is an entity external to the behaving artifact (the doer). We conceptualize the two processual roles through two specialisations of the participation relation: $participatesAsDoer (\cdot, \cdot, \cdot)$ , to indicate participation in a process with the role of an agent or agent-like doer, and $participatesAsFlow (\cdot, \cdot, \cdot)$ , for the role of flow:

$participatesAsDoer (x, y, t) ⟹ (TechArt (x) \lor ASO (x)) \land Behaviour (y) \land PC (x, y, t)$

“if x is a doer in y at time t then x is a technical artifact or an agent, y is a behaviour, and x participates in y (in the DOLCE sense) during that time”

$participatesAsFlow (x, y, t) ⟹ Behaviour (y) \land PC (x, y, t)$

“if x is a flow in y at time t then y is a behaviour, and x participates in y during that time”

$Behaviour (x) ⟹ \exists y, z, t (participatesAsDoer (y, x, t) \land participatesAsFlow (z, x, t) \land y \neq z)$

“x is a behaviour only if there are at least a doer and a flow that participate in x”

From (a9) it follows that behaviours are perdurants. Additionally, we assume that behaviours can be combined to give causal explanations of complex perdurants (e.g. the beam was cut, therefore it fell to the floor), and formalize this with a binary relation called causal contribution,24

²⁴

This relation among perdurants is inspired by the one introduced in YAMATO [68]. Note that the latter is limited to YAMATO processes.

which we assume holds more in general between perdurants:

$causalContr (x, y) ⟹ PD (x) \land PD (y)$

We do not axiomatize the causal contribution relation further as it has a much broader scope than the focus of this paper but see [10] for an initial proposal.25

²⁵

Note that Borgo and Mizoguchi constrain the relation of causal contribution so that its domain and range are processes. In [71], the authors argue that the same relation can also apply to a process and a state, with the convention that, whenever that happens, it holds between the first process and the process of achieving the state. Here, we take a broader view and set the domain and range to be the category of perdurants.

Similarly, we do not axiomatize the roles of doer and flow, see [59] for a deeper discussion of these notions.

The role-based approach combined with the causal contribution relation allows us to model behaviour from the point of view of the participating device (a9). Admittedly, it also introduces some limitations. For instance, the case of an artificial agent changing its own setting exemplifies a function where doer and flow coincide, a case ruled out by (a9) (such a function is called ‘change over’ in [6]). A full analysis of the relationships between the two approaches to behaviour (relational quality vs. perdurants with roles) has not been carried out. We highlight once more that they are mutually compatible within DOLCE. When using behaviour from now on, we will mean engineering behaviour unless otherwise specified.

Having conceptualized behaviours as a role-based view of perdurants, we spend a few words about the notion of state of an engineering system. In DOLCE states are, as mentioned in Section 3, cumulative and homeomeric perdurants. The same properties should hold for engineering system states. Indeed, if we understand states, as many engineers do, as conditions determined by constraints over state variables, then such conditions are homeomeric (if a device satisfies a constraint over a time period, then it also satisfies it during a fragment of that period) and cumulative (if a device satisfies a constraint over some time periods, then it satisfies it during the union of those periods). Unfortunately, engineers commonly use the term ‘state’ also for oscillating phenomena and the like (e.g. the buzzing action of a clapper, which alternates between two different DOLCE-states while buzzing, namely open-circuit and closed-circuit). Hence, the right DOLCE category to conceptualize system states is the one of stative perdurants. To avoid a terminological clash, in the following we will use the term ‘state’ following the engineering terminology. Ontologically, it is to be understood as a ‘stative condition’ in DOLCE. For this reason, we will use the stative predicate $STV (\cdot)$ in formulas.

Finally, engineers typically know how to characterize a state a system should be in, therefore we assume that, given a technical artifact, some ‘types’ of states are selected as desired, and call them goals. Note that, typically, one selects the conditions that a state has to satisfy, that is, selects a concept and not a state-instance, since the latter would have a specific time extension. Hence, we have that

$Goal (x) ⟹ CN (x) \land \forall y, t (CF (y, x, t) \to STV (y))$

“a goal is a concept that classifies stative perdurants only”

Thus, goals may correspond to expressions ‘the temperature at the port B of the heat exchanger is between 80 and 110 Celsius degrees’ and ‘the buzzer is clapping with a frequency of at least 10 kHz’, which are expressions for state classifiers.

4.2. Systemic functions and ontological functions

Systemic functions In this paragraph we exploit the concepts introduced in the previous sections and propose a preliminary formalisation of ontological functions as roles. Precisely, we start by defining systemic functions. In doing that, we are mainly inspired by the definition presented in [71] (cfr. also Cummings’ definition in [20]), from which we also take the concept name. Such a definition is based on the so-called systemic view of devices, that is, on the idea that devices are complex aggregates of components, whose interaction with the rest of the system contribute to generate the activity of the whole system. In this context, a function is seen as the contribution of an individual component’s activity to the activity of the system as a whole, and teleological aspects are introduced through goals imposed on the system. Note that our notion of behaviour (a perdurant with roles) is different than the one in [71] and presents a nice feature: with our approach it is very simple to decompose (and to recompose) the system’s behaviour into components’ behaviours as the latter are simply parts of the first (provided one correctly identifies the suitable roles).

${FunctionOf}_{Sys} (x, y) ⟺ (RL (x) \land \exists z, g, b, t (System (z) \land goalOf (g, z) \land CF (b, x, t) \land P (y, z, t) \land \forall b^{'}, t^{'} (CF (b^{'}, x, t^{'}) ⟹ (Behaviour (b^{'}) \land participatesAsDoer (y, b^{'}, t^{'}) \land P (y, z, t^{'}) \land causalContr (b^{'}, g)))))$

“x is a systemic function of y if and only if x is a role and there exist a system z and a goal g for z such that x classifies only behaviours which have y as doer and part of z, and that causally contribute to achieve g”26

²⁶
This means that the term ‘systemic’ in ‘systemic function’ refers to the dependence of such role-concept to a system, and does not imply that the player artifact is a system itself. For example, if a wood table is held together by screws, each screw has a systemic function in the table-system: it connects one of the table-legs to (a side of) the table-top, even though none of the screws is a system.

${Function}_{Sys} (x) ⟺ \exists y {FunctionOf}_{Sys} (x, y)$ “x is a systemic function if and only if it is the systemic function of some object y”

Of course, there are many different function conceptualisations in the literature and each is relevant from one engineering perspective or another. We propose to start from Definition (d8) because, differently from the others, it is ontologically clear and helps to clarify the assumptions on which other meanings rely.

Note that, observing Definitions (d8) and (d9), it is natural to assume that systemic functions are definition-founded on systems, a fact that we introduce with the following axiom:

${Function}_{Sys} (x) ⟹ \exists y (System (y) \land {founded}_{Def} (x, y))$

“each systemic function is definition-founded on some system”

Ontological functions In engineering practice, one may speak about functions independently of any system, for instance in an early system design phase. For example, if one wants to address the problem of finding the set of devices that have the capability of realizing a needed transformation, the devices cannot be a priori associated with a certain system, since there is no system yet. Indeed, the system is a variable input of the problem. Therefore, to solve this problem, a more general concept of function is needed, see, e.g., [6]. We call such functions ontological functions as they are relative only to the upper ontology one is using. The idea is that these functions distinguish very general transformations without addressing how such a transformations may occur or to which entities they apply. The informal intuition of ontological functions is that they are classified primarily according to the ontological difference(s) they enforce between the input and the output states. In this sense, they are independent of systemic functions.

For instance, assume we want to model a walking activity as the realization of a moving function. Walking may be considered a simple action but is very complex to model since it is a highly coordinated, continuous and dynamic process. One might decide to simplify its modeling by “restricting” the walking model to some aspects, such as the variation of the distance of the feet from the floor, the trajectory of the body’s center of mass, the changing contact forces between the feet and the floor, those developing into the leg joints, and so on (cf. [33]). It turns out that there are many aspects that one may focus on. Which should one use?

Assuming that an upper ontology is fixed (DOLCE in this paper), one considers the state transitions that are made available by the ontology and that are relevant to the transition of interest. In the case of walking, the relevant feature(s) that characterize a walking in the upper level of DOLCE are the change of location of the entity. At this high level, among the entities relevant to walking, the ontology makes available only space and location qualities. Other classes, like foot or center of mass, and other qualities, like speed and force, are not characterized nor committed to. The perdurant could not be said to be a walking since DOLCE has no walking category nor the needed ontological commitments to introduce such a category. If walking at this level can be characterized only by the change of the location quality, then one cannot distinguish it from swimming or flying (this depends on the upper level ontology, different ontologies may be more or less rich). One may wonder whether this level of characterization is too weak to be used for functional modeling. It is not. Already at this level one can make substantial differences since one can distinguish cutting from walking. Cutting is characterized by the presence of one entity at the initial state and two or more at the final state, walking is not. (In DOLCE, like most (perhaps all) upper ontologies, entities can be distinguished in number, thus cutting and walking are different types of perdurant even at this level.) Since functions are realized by perdurants, we can use this ontology-driven categorisation of perdurants to introduce a categorisation of functions. Let us call ontological functions the functions that are carried out by transformations characterized by the ontological commitments (thus, distinctions) present in the upper ontology. As said, this provides only a high level (coarse) characterization of functions. Since the resulting taxonomy of functions strictly depends on the ontology adopted, we use the qualifier “ontological” and call them ontological functions (where more than one upper level ontology is used, one should be more precise indexing the ontological functions by the ontology they depend upon, e.g., ‘DOLCE-ontological functions’). Continuing the discussion with DOLCE as the upper ontology, the ontology makes available the categories region, quality, physical object, amount of matter, etc. (see Fig. 1), which give rise to several ontological function-types based on change in quality-value (for example, the controller increased the internal temperature of the oven), change of physical object (e.g., the employee assembled four legs and a table-top to form a table), change of amount of matter (e.g., the water was vaporized by the boiler), and so on.

Fig. 2.

A non exhaustive taxonomy of the logical formulas describing changes between states, classified depending on what predicates differ between the initial and final states.

Fig. 3.

An example of how a taxonomy of ontological functions could be organized. The rounded white rectangles contain the ontological functions-categories (classes of perdurants with identified doer and flow roles). The gray circles are functional concepts used to specialize ontological functions as in (d13), and refer to Fig. 2. The rectangles with sharp corners list alternative terms used in the literature to label that functional concept: H, P&B, and O refers to [37,78], and [87], respectively. (Notice that terms may occur in the literature also with different meanings than in this figure.) The same perdurant may be classified by more than one functional concept. ‘Amount of Energy’ is listed only for the sake of example, it is not part of DOLCE.

Note that an ontological category can be involved in a transition in different ways. For example, an instance of said category could be eliminated, meaning that the instance was present in the state before the transition but not after, or an instance could be created, meaning that the instance was not present before a transition but exists after. Another possibility is that there is a change of a relation of the ontology, e.g., in the initial state there were two individuals that were, say, one part of the other, while in the final state they are not. More complex changes can be described, depending on the difference between the initial and final structure of the ontology. We have reported some of these cases in Fig. 2, which is not exhaustive, while in Fig. 3 these cases combine with the aforementioned ontological categories to produce different ontological functions. Note also that in most cases the same event may be classified by several ontological functions. For instance, an event of cutting by a device, say a knife, is also a squeezing event, i.e., a compression (a change of the shape quality of the initial object) and a moving event (a change of the device location relatively to the object’s location). Clearly, most of these distinctions are similar to those obtained via the ontological analysis of events [33]. Finally, the functional terminology used in this paragraph is inspired by engineering literature which, as we have seen earlier, is not homogeneous. For instance, the reclassification (i.e., a change such that an instance changes type) of energy or matter is in other places called ‘convert’ [37,87] or ‘change’ [78] or ‘transform’ [47], while the change of value of a spatial location quality is called ‘channel’ [37,78], and so on.

Functional terms that are linked to domain-level terms (e.g., ‘vaporize’, ‘moisten’, ‘heat’) are not captured at the lever of ontological functions and require a domain or middle-level ontology containing corresponding concepts (e.g., vapour, humidity, temperature) in order to expand the construction we have just described up to that level of ontological distinctions. The ontological nature of some concepts, like ‘energy’, is unclear [67] despite being a fundamental concept in engineering and physics. Nonetheless, given an ontology containing a conceptualisation of energy, it is possible to introduce a corresponding ontological function, which might be different in another ontology with a different conceptualisation of energy. For instance, one could conceptualize energy as a quality, as done in [5]. This is the case, arguably, when one speaks about the energy of something, e.g, of a battery. In this case, in our ontology there would be a, say, energy content quality-type, which gives rise to a corresponding convert energy ontological function. Another possibility is to conceptualize energy as an endurant, which can reside into entities, change its location, and change type (e.g., heat energy, kinetic energy, etc.). In that case, the convert energy ontological function would be a reclassification-type transformation.

Formalizing ontological functions, like formalizing events, might be difficult. One would benefit from the introduction in the ontology of a general relation ‘change of …in event …’. An ontological function, as understood in this paper, is essentially an event classifier which looks at what changes (or remains stable) in the event. This suggests defining specific functions by comparing, for instance, initial and final states. For example, a connect function could be introduced as follows:

$Connect (x) ⟺ (CF (y, x) ⟺ E (y) \land \exists a, b, c, s_{i}, s_{f}, t_{i}, t_{f} (startState (y, s_{i}, t_{i}) \land endState (y, s_{f}, t_{f}) \land Goal (s_{f}) \land POB (a) \land POB (b) \land POB (c) \land PC (a, s_{i}, t_{i}) \land PC (a, s_{f}, t_{f}) \land PC (b, s_{i}, t_{i}) \land PC (b, s_{f}, t_{f}) \land PC (c, s_{f}, t_{f}) \land P (a, c, t_{f}) \land P (b, c, t_{f})) \land \neg \exists c^{'} (POB (c^{'}) \land PC (c^{'}, s_{i}, t_{i}) \land P (a, c^{'}, t_{i}) \land P (b, c^{'}, t_{i})))$

“A connect function is a classifier of events that are transitions between a starting state ( $s_{i}$ , with time extension $t_{i}$ ) and a final state ( $s_{f}$ , with extension $t_{f}$ ) and two entities (a and b) participate in such states such that in the final state, but not in the starting one, they form a single object (c)”

In the previous formula we used the predicate

startState (y, s_{i}, t_{i})

to mean that

s_{i}

is a state with time extension

t_{i}

, which is part of the perdurant y and such that there are no parts of the time extension of y which precede

t_{i}

. Analogous meaning for

endState (\cdot, \cdot, \cdot)

. Notice that:

(a)

this notion captures the act of forming a single object out of two given ones, to formalize an assembly function one should add the condition that the final object is also a single piece (self-connected);

(b)

if one reverses the initial and final states in Formula (d10), then one obtains a definition for the divide function.

Another example, to define a convert function (here Φ and Ψ are types belonging to the set $NR$ of all non-rigid types of the underlying ontology):

$Convert (x) ⟺ (CF (y, x) ⟺ E (y) \land \exists s_{i}, s_{f}, t_{i}, t_{f}, a, Φ, Ψ (startState (y, s_{i}, t_{i}) \land endState (y, s_{f}, t_{f}) \land Goal (s_{f}) \land Φ \in NR \land Ψ \in NR \land Ψ \cap Φ = \emptyset \land PC (a, s_{i}, t_{i}) \land PC (a, s_{f}, t_{f}) \land Φ (a, t_{i}) \land Ψ (a, t_{f})))$

“A convert function is a classifier of events that are transitions between a starting state ( $s_{i}$ , with time extension $t_{i}$ ) and a desired final state ( $s_{f}$ , with extension $t_{f}$ ) and, moreover, there is an entity (a) that at time $t_{i}$ is instance of a type (Φ), while at time $t_{f}$ is instance of a different, disjoint, type (Ψ).”

Notice that in the previous definition we have quantified over the set of all non-rigid classes of an ontology (

NR

). If such a set is finite, like in DOLCE, then the quantification corresponds to a finite disjunction of predicates, therefore Formula (d11) is a first-order formula. Moreover, upper-level ontologies typically contain only rigid categories (e.g., if an individual is a physical object, it is always a physical object), therefore, such a convert function becomes useful when modelling changes in entities that go through phases [35], when modelling entities that change their processual role (as described earlier) or in combination with non-rigid categories (as provided by middle or domain-level ontologies).

The type of all ontological functions that involve some change in quality values (cf. qualitative events in [33]) could be defined as follows:

$ChangeQV (x) ⟺ (CF (y, x) ⟺ E (y) \land \exists s_{i}, s_{f}, t_{i}, t_{f}, a, q, v_{i}, v_{f} (startState (y, s_{i}, t_{i}) \land Goal (s_{f}) \land endState (y, s_{f}, t_{f}) \land qt (q, a) t_{i} \land qt (q, a) t_{f} \land v_{i} \neq v_{f} \land PC (a, s_{i}, t_{i}) \land PC (a, s_{f}, t_{f}) \land ql (q, v_{i}, t_{i}) \land ql (q, v_{f}, t_{f})))$

“A change of quality-value function is a classifier of events that are transitions between a starting state ( $s_{i}$ , with time extension $t_{i}$ ) and a desired final state ( $s_{f}$ , with extension $t_{f}$ ) with a participating entity (a) which has a quality (q) with different values, $v_{i}$ and $v_{f}$ , at times $t_{i}$ and $t_{f}$ , respectively.”

One can further specialize this latter notion. If the quality in formula (d12) is spatial location, the ontological function will be of type channel. If the quality in (d12) takes values in an ordered space (e.g., temperature, humidity, etc.) then the ontological function is of type vary, possibly specialized into increase and decrease types, see [37,78]. Some functions, such as store and support, hint at the absence of change: for instance, a battery stores energy very well if it does not lose its charge over time, while a load-bearing wall supports the roof only if the roof does not fall. Therefore, functional concepts like store and support could be defined by modifying formula (d12) to impose that the initial and final values of the quality are the same (perhaps including some tolerance).

At this point we make three observations:

By construction, ontological functions cannot be fine grained. On the one hand, they are limited to the language of the upper ontology. On the other hand, they do not consider at what happens between the initial and final states. Take, for example, a temperature-controlled oven. The controller unit of the oven makes it so that the temperature in the oven stays, up to some tolerance, at a target value. The controller could achieve this by switching off the heat when the temperature is above the target value, and by switching on when the temperature is below the target. The temperature value oscillates around the target value, and such a process cannot be deduced by only observing the differences between the initial and final states. Therefore, events that maintain a stable temperature vs. events in which it oscillates cannot be distinguished by ontological function unless one enriches the function definitions by allowing further conditions to constrain the temperature value during the event (e.g., via variation patterns, see [33]). This is in line with our view of ontological functions but recall that one should consider only conditions that are expressible within the language of the ontology.

Events can be very complex and participated by many relevant entities (e.g., walking from a biomechanical point of view). This, together with the fact that we admit also ontological functions defined by the absence of some type of change (e.g., support), makes so that many events would be classified by a combination of ontological functions (as observed earlier while discussing the cutting example). This is not unexpected, and, in fact, reflects the flexibility of teleological thinking. Take, for example, a load-bearing wall. One could say that its function is to support the weight of the roof, but it may also transmit the load to the floor, or even stop the wind from entering the house, or divide the space inside the house into smaller rooms, and so on. To recognize what aspect is the most relevant in a given context is a task for the engineer or technician, which, using a contextual viewpoint, determine what aspects to focus on and thus the target function. This is the reason for using the term ‘function’ (in combination with ‘ontological’) to characterize these classifiers. Events, by their nature, are open to different interpretations.

Lastly, we argue in favour of the flexibility of ontological functions. In the previous paragraphs, we have mainly used functional terms taken from the Functional Basis [37] or from the influential view of [78]. Such vocabularies are indeed capable of expressing a vast quantity, if not the totality, of functions used within engineering domains, but they may not do so in the most natural way. For example, suppose that one is working with tooling machines that cut holes, slots, grooves, etc. in the workpieces. Then, using the Functional Basis one is reduced to using just the term remove to talk about the functions realizing such features in the workpiece. Instead, if one uses a domain ontology that contains concepts such as hole, slot, groove, etc., then one can build corresponding functional terms, say make hole, make slot, to groove, etc., defined analogously to the previous formulas. Such terms may be more natural than just using ‘removing’, and may even differ significantly from ‘removing’, depending on their precise formalisation. Another example: in the Functional Basis vocabulary, the term ‘stop’ means ‘to cease the transfer of a flow’, for instance ‘A reflective coating on a window stops the transmission of UV radiation through a window’ [37]. But what if perdurants are important in our domain and we want to say that something stops a process (e.g., “The addition of a respiratory inhibitor stops the absorption of amino acids”, not that “stops the amino acid-material-flow from moving”, but that it “stops the absorption”, where absorption is an important element of the domain? We could derive useful functional terms, from an appropriate domain ontology managing concepts of domain processes.

Up to this point we have defined some types of ontological functions, but not the concept of ontological function itself. A possibility is to find an exhaustive list of types of ontological functions and then define ontological function as the disjunction of all those types, for instance:

${Function}_{Ont} (x) ⟺ (Connect (x) \lor Divide (x) \lor Convert (x) \lor \dots)$

This can be done by providing an exhaustive list of ontological functions made available by an upper ontology. Another possibility is to look for an intrinsic definition of ontological functions that informally could be as follows:

“A concept is a ontological function if and only if it classifies exactly those events consisting in a transition such that the changes (or the absence thereof) between the initial and final states (or across the whole transition) is characterized in terms of a formula expressed in the language of an upper ontology.”

Since “a formula expressed in the language of an upper ontology” is not something that can be written in a natural way using first-order logic, we cannot give an intrinsic first-logical definition of ontological functions. (A similar argument could be applied to extend the notion of ontological functions to functions in the language of reference ontologies.)

Link between systemic functions and ontological functions Returning to the relation between systemic functions and ontological functions, we observe that the former correspond to system-dependent functional descriptions, while the latter corresponds to system-independent functional descriptions. Since ontological functions are more general than systemic functions, they can be used to classify them:

${Function}_{Ont} (x) ⟹ (\exists y (SP (y, x) \land {Function}_{Sys} (y)) \land \forall y (SP (y, x) \land \neg {Function}_{Ont} (y) ⟹ {Function}_{Sys} (y)))$

“any ontological function x is specialized by some systemic function y and, beside ontological functions, classifies systemic functions only.”

For example, take a tooling machine as a system, e.g., a lathe, and assume that it makes use of two electrical motors: one for rotating the spindle and the other for moving the spindle horizontally. Both electrical motors perform the same ontological function of ‘converting’ (electrical energy into mechanical energy), but they also perform two different systemic functions specializing the ontological function in the context of the lathe: ‘converting (electrical energy into mechanical energy) to rotate the spindle’, and ‘converting (electrical energy into mechanical energy) to translate the spindle’, respectively. The intuition is that we can group systemic functions together through common characteristics, along the lines of definitions (d10) to (d12), abstracting from specific systems or from their occurrences in different parts of the same system.

Fig. 4.

The scheme of a hydraulic system, taken from [60].

Finally, notice that the two types of functions introduced in this paragraph cover at least two different ideas of functions used by engineers. First, there are ‘general’ functions that engineers use when they need to, say, describe information about or collect information from different systems. For example, Collins [19], when collecting and analyzing failure experience data, speaks of ‘elemental mechanical functions’, which are application-independent characterisations of ‘basic’ functions. Analogously, Pahl et Beitz [78] speak of ‘generally valid functions’, and propose them as references for cataloguing design knowledge about function implementation. These types of functions can be approximated via ontological functions. In contrast, a second meaning used by engineers is system-dependent. In general, when engineers focus on a single system, they use different concepts to speak about the system components. The terminology is varied, but typical terms are ‘serial number’, that is the identifier of a component-instance, ‘component code’, i.e. the component or assembly-type identifier, and ‘functional location’ or ‘tag’, which are identifiers that consider also the position of a component within a system. For example, Fig. 4 schematises a hydraulic system containing four solenoid valves, whose tags are EPF1 to EPF4. These tags cannot refer to the valve-type, since the four valves could have the same type, nor they can refer to the valve-instances, since schema are generally used to represent different system-instances. In our terminology, we could say that tags identify roles that components play in a system. Necessarily, these roles are of functional nature, for each component in an engineering system has a role in the system function. Thus, tags or, at least, the teleological content they carry, could be formalized by systemic functions.

4.3. Functional decomposition

An important feature of functions in engineering is the possibility to decompose them into sub-functions. This also allows to refine the granularity of the system description. In this paragraph, we show how such decomposition relation can be used in order to formalize the difference between ontological functions and engineering functions that we described earlier.

First, observe that such decomposition cannot be reduced to a partial order relation between functions. That is, if we represent the functional decomposition of a function, say $f$ , into sub-functions, say $f_{1}, f_{2}, \dots, f_{n}$ , as $decomp (f; f_{1}, f_{2}, \dots, f_{n})$ , then it does not seem possible to find a parthood relation such that $decomp$ reduces the mereological sum. This is caused by, at least, the following reasons:

Functions exist at a teleological level, therefore, any decomposition of functions must take into account the decomposition of the underlying objective substrata, that is, of the underlying behaviours and objects.

The sub-functions of a function must ‘organize’27

²⁷
We borrow the term from Vermaas and Garbacz [99], in there the interested reader can find a discussion about mereology in functional decomposition, especially with respect to the Functional Basis methodology.

in order to realize the decomposed function. In particular, the composition of a mere set of functions is not unique.

The same function can be decomposed in more ways, therefore the decomposition relation is of type many-to-many.

Not all combinations of sub-functions are possible, due to physical and technical constraints. Moreover, among all possible combinations, engineers recognize typical ones and use them systematically.

Additionally, Vermaas has proven that attempting to model a Functional Basis style of functional decomposition28

²⁸

That is, a style where functional models can be graphically represented as directed graphs with flows as edges and function as nodes. The composition, then, can be in series, between nodes that share an edge (canceling that edge), or in parallel, between nodes that do not share edges.

entails contradictions [100],29

²⁹

The counterexamples shown are based on some additional assumptions. Precisely that, first, if a function-token is part of another function-token, then the same holds for the corresponding types; and, second, that flow loops are possible.

so that there are also formal obstacles preventing the application of classical mereology to functional decompositions. We do not attempt a solution to these problems here, instead we assume that the relation

decomp

is given, and focus on engineering methods.

Inspired by the work of Kitamura et al. on ‘ways of functional achievement’ [43,45], we consider engineering methods as non-agentive social objects representing the knowledge that engineers share about ways of implementing functions through functional decomposition:

${Method}_{Eng} (x) ⟹ NASO (x)$

Formally, such non-agentive social objects can be understood as reifications of functional decomposition relations. Precisely, we introduce roles

mainFunction (\cdot)

and

subFunction (\cdot)

, contextualized by a decomposition, such that:

$(mainFunction (x) \lor subFunction (x)) ⟹ (RL (x) \land \exists m ({Method}_{Eng} (m) \land founded (x, m)))$

“main-functions and sub-functions are roles founded on some engineering method”

Additionally, we assume that methods are always contexts for a main-function and for a certain number of sub-functions (axiom (a16)^∗ is actually a meta-axiom, for this reason we mark it with a ∗-symbol).

${Method}_{Eng} (m) ⟺ \exists! n {Method}_{Eng,Sub} (m, n)$ , and n is integer

“Each method, say $m$ , has a (unique) number, say n, of sub-functions that are contextualized by the method”

Note that, given a finite set of methods, the previous axiom can be substituted with a finite set of axioms in FOL. The following condition constrains the decomposition relationship and is expressed via an axiom schema (here n is an integer):

${Method}_{Eng,Sub} (m, n) ⟹ \exists! main, su b_{1}, \dots, su b_{n} (mainFunction (main) \land subFunction (su b_{1}) \land \dots \land subFunction (su b_{n}) \land founded (main, m) \land founded (su b_{1}, m) \land \dots \land founded (su b_{n}, m))$

“for any engineering method of functional decomposition, say $m$ , having a given number of sub-functions, say n, there exist a main-function role and n sub-function roles, which are founded on $m$ and are uniquely determined”

Since the main-function and the n sub-functions roles of a given method are univocally determined, we can represent them with functional symbols. In particular, we will write

mai n^{m}

{sub}_{1}^{m}

, …,

{sub}_{n}^{m}

to indicate the roles corresponding to the method

m

, as per Axiom (a17) (we omit the functional dependence of n on

m

, for ease of notation). Finally, the link between methods and decompositions is given in the following definition schema:

$decomp (f; f_{1}, f_{2}, \dots, f_{n}) ⟺ ({Function}_{Sys} (f) \land {Function}_{Sys} (f_{1}) \land \dots \land {Function}_{Sys} (f_{n}) \land \exists m ({Method}_{Eng} (m) \land SP (f, {main}^{m}) \land SP (f_{1}, {sub}_{1}^{m}) \land \dots \land SP (f_{n}, {sub}_{n}^{m}))$

“ $f$ is decomposed in $f_{1}, \dots, f_{n}$ if and only if they are all systemic functions and there is a method with corresponding main-function ${main}^{m}$ and sub-functions ${sub}_{1}^{m}$ , …, ${sub}_{n}^{m}$ , which are specialized by $f$ and $f_{1}, \dots, f_{n}$ , respectively”

The advantage of this approach is manyfold: it makes possible to organize the method-types within sumbsumption taxonomies, for example, ‘spot welding’ is a specialisation of the method ‘welding’, which itself is an implementation method of the function ‘to join’; and to describe the properties of the methods, for instance the working principle, say Kirchhoff’s law for a ‘voltage divider’ method. Additionally, it makes possible to introduce properties of functional decomposition. For example, if one wishes to express that all functions are decomposable, she can state:

${Function}_{Sys} (x) ⟹ \exists y mainFunction (y) \land SP (x, y) \land x \neq y$

Instead, if one wishes to state that a function, say

f

, is not decomposable:

$\neg \exists y (mainFunction (y) \land SP (f, y) \land f \neq y)$

Moreover, this approach allows us to give a formal definition of engineering function and, thereby, to discuss the ontological difference between capacities and capabilities. In fact, we define engineering functions to be main functions

${Function}_{Eng} (x) ⟺ mainFunction (x)$

“engineering functions and main-functions coincide”

so that engineering functions are roles that systemic functions, which are defined in (d9), can play in the context of a functional decomposition. For instance, in the lathe example discussed above, it could be that the systemic functions of the two motors are both implemented through the method of, say, ‘three-phase electric motor’, and, therefore, play the role of engineering functions. In this case, the functional decomposition entailed by the method includes sub-functions roles for, say, ‘supply electrical energy’ (one per each phase), ‘drive the motor’, and ‘output mechanical energy’.

5. Capabilities and capacities

In this section, we discuss capabilities and capacities, two notions that we briefly introduced at the end of Section 2. In particular, we will make use of the concept of ontological function to distinguish capabilities from capacities. That is, we ground the distinction on an ontological argument moving beyond views like ISO 15531-31 [39], which proposes the association of capacities with a quantitative viewpoint and capabilities with a qualitative viewpoint only on the basis of practical arguments.

Recall that the characteristics of a technical artifact are part of its physical make-up and determine how the artifact interacts with its environment. For example, an individual pump is built in such a way that it is able to pump water with a certain flow rate. Following the quality theory of DOLCE, both the physical characteristics of the technical artifact and its ‘being able’ to do something can be conceptualized as individual qualities.30

³⁰
As seen in Section 3, individual qualities in DOLCE have associated quality spaces, which are essentially types of conceptual spaces as introduced in [26]. In the case of capabilities, which are relational qualities, the associated quality spaces should include also (at least some) dimensions relative to the entities needed for the capability to be realized.

Consequently, we can model the capacity ‘flow rate’ (something that can be quantified) as a relational quality of the artifact relative to a certain kind of fluid, and the capability to pump (something that realizes a type of interaction or ability) of the same artifact as another (yet related) relational quality. But what are these capabilities? Our theory provides a natural explanation: an entity has a capability if it can participate as doer in an ontological function. More precisely, an entity has a capability of a certain type (it has the capability of dividing) if and only if it can participate in the role of doer in an ontological function of the corresponding type (it can participate as doer in a event classified by the divide function). Thus, we assume that ontological functions define types of capabilities, and that an entity has a capability only if it can perform (participate as doer) the corresponding ontological function. Starting from this level of capabilities (which we could call ontological capabilities), one can specialize capabilities to lower functional levels where functions like cutting, loading etc. are introduced, thus characterizing cutting capability, loading capability and so on.

5.1. Capabilities vs. capacities

Whenever a capability is based on some other quality of a technical artifact, that is, when each realisation of the capability depends on some other quality, we say that it is founded on that quality (or qualities). As before, we formalize this through the relation $founded (\cdot, \cdot)$ defined in (d4). For example, in the case of the pump we could say that the capability of the pump to move water is founded on its flow rate capacity. Coming back to Gero and Qian’s example of the water tap mentioned in Section 3, which is similar to the one of the pump, we could say that the faucet has the capability of delivering water when requested, which is founded on its flow rate capacity, which is itself founded on its diameter quality (Gero and Qian say that the flow rate is ‘controlled’ by the diameter [80]). Now, in this example, there is a difference between the flow rate and the diameter: the latter is an intrinsic quality and the former is a relational quality, as we argued in Section 3. These examples suggest that capacities are those relational qualities on which a capability is founded, analogously to the approach in [11]. The point is that capacities are relational qualities that provide information about how the corresponding capability can be realized in practice. Going back to the pumping example, we conclude that the flow rate capacity parametrizes, perhaps only partially, the pumping capability.

Another example: electronic components such as resistors, transistors, etc., are accompanied by a datasheet that reports technical properties of the devices. Typical properties are, for example, the failure rate and the maximum temperature, current, or voltage that the component can reliably operate with in standard conditions. In our terminology, all the aforementioned properties are capacities: these properties are manifested only when the component is inserted into a working electrical circuit;31

³¹
As mentioned earlier in the paper, a clear-cut example is the voltage, which, since it is a potential, needs a fixed reference point in order to be measured.

and they parametrize some capability of the component like, say in the case of a resistor, to create a voltage drop.

Capacities themselves are founded on some intrinsic physical qualities of the bearing object. For example, the maximum operating current will depend on the geometric and electrical properties of the conductor metal, such as its diameter and its resistivity. Similarly, the flow rate of the water tap depends on its diameter. Given these observations, we characterize capacities as follows:

$Capacity (x) ⟹ relationalQt (x) \land \exists y (founded (x, y) \land intrinsicQt (y) \land bearer (x) = bearer (y))$

“A capacity is a relational quality and is founded on some intrinsic quality, which is carried by the same bearer.”

In (a18), the

bearer (\cdot)

is the (unique) bearer of a quality, i.e.:

$bearer (x) = ι y (qt (x, y))$

“the bearer of a quality is the entity that has (inheres) the quality”

$Capacity (x) ⟹ \exists y (Capability (y) \land founded (y, x))$

“Each capacity founds a capability.”

Axioms (a18) and (a19) do not fully define what a capacity is. They only give some constraints. Modelling the relation between capacities and capabilities remains complicated and requires further investigations. Yet, a promising way to tackle the problem is to define a capacity as a ‘parameter’ of the capabilities it founds, that is, as a quality such that its values are always related to the conceptual space of the corresponding capability:

$Capacity (x) ⟺ relationalQt (x) \land \exists y, z (founded (x, y) \land intrinsicQt (y) \land founded (z, x) \land Capability (z) \land bearer (x) = bearer (y) = bearer (z) \land \forall u, t (ql (u, z, t) ⟹ \exists v (ql (v, y, t) \land P (v, u, t))))$

“Capacities are precisely those relational qualities that are founded on some intrinsic quality (of the same bearer), and which found some capability (of the same bearer), such that every time that the capability takes a range-value (u), the capacity takes a value (v) which is part of u.”

Briefly put, the formula above views capacities as the parameters of capabilities allowing to ontologically support practical approaches like, e.g., that of ISO 15531-31 [39].

5.2. Capabilities vs. functions

From another perspective, capabilities are inextricably intertwined to functional aspects. To be able to do something is, arguably, a modal concept calling for possible events in which that something is actually done. Possible events are already part of the DOLCE ontology so we can write the following (where e is a possible, perhaps not actual, event):

$\exists c (PumpingCapability (c) \land qt (c, x)) ⟺ \exists e, t (participatesAsDoer (x, e, t) \land PumpingProcess (e))$

“An object x carries an individual capability of pumping if and only if there is a possible perdurant during which x realizes some pumping process”

Since the introduced capabilities are specifically dependent on their bearers, and each capability of a certain kind is unique to its bearer, we treat them as individual qualities.32

³²
An alternative is to model them as disposition, see for instance [86], and [63] for a broader introduction to dispositions.

Finally, note that Example (ex4) also seems to suggest that capabilities depend on types of functions (not just processes or behaviours, for the pumping process in (ex4) will always play a function), which are used in their definition. This suggests to adopt the definition-founding relation already introduced in Section 3:

$Capability (x) ⟺ relationalQt (x) \land \exists y ({Function}_{Ont} (y) \land {founded}_{Def} (x, y))$

“x is a capability if and only if it is a relational quality definition-founded on some ontological function”

Additionally, we assume that each capability is parameterized by at least a capacity (cf. (a19)):

$Capability (x) ⟹ \exists y (Capacity (y) \land founded (x, y))$

“A capability is founded on some capacity”

From this axiom, we have that capabilities are specifically dependent on capacities, which specify how the artifact (the bearer) can function. The intuition, as anticipated at the beginning of this section, is that capabilities are relational qualities that associate their bearers with ontological functions, so that they must refer to those functions: in our terminology, they are definition-founded on ontological functions. Note that they are not instantiation-founded, see (d5), since an artifact could have the capability to function without actually functioning. Additionally, the function must be ontological and not systemic because, otherwise, the bearing object would be associated a priori with some given system.

The characterization of capacities and capabilities via (a18), (a20), and (d18) has the advantage of explaining:

the close link between functions and capabilities (capabilities are definition-founded on ontological functions);

the asymmetry between capacities and capabilities (capabilities are founded on capacities, but not vice-versa).

The quantitative-qualitative difference between capacities and capabilities anticipated at the end of Section 2 is only partially clarified by this approach. For instance, while a flow-rate capability takes as values positive real numbers with, say, m³/s as unit of measure, the value space of the corresponding pumping capability is quite more complex and difficult to describe.

One reason for the difficulty in defining capacities and capabilities is the relational and potential nature (in our interpretation) of these concepts: they are relational, and we have attempted to capture it with relational qualities, since they need the relation between their bearer and its environment to make sense; and they are potential, in the sense that they are strictly related to events that may occur, but need not to actually happen. Functions are, arguably, similar to capabilities in this aspect, and this may partially explain the terminological and conceptual complexity that these concepts bring. Of course, these concepts are not the only ones to be both puzzling and commonly used in engineering: affordances are another well-known example. As mentioned at the end of the literature review, engineering affordances are often defined as “interaction between artifact and user in which properties of the artifact offer a potential use to the user” [62], but this is not an universally shared definition, and conceptual confusion persists in the disciplines (not only engineering) that make use of this concept. We do not attempt to carry out an ontological analysis of affordances, but we do make two brief observations:

first, the reasons for the confusion around the concept of affordance may be, at least partially, the same for the concepts analyzed in this paper. They strongly depend on relations between entities, and they are potential concepts, as opposed to actual.

Second, one could attempt to reduce affordances to capabilities using, for example, the following informal equivalence:

“An engineering artifact affords a user (or another artifact) to do something if and only if the system made by the artifact, the user (or the second artifact), and their relation has the capability to do that something”

From this point of view, our analysis of capabilities would carry at least some insight into affordances.

Finally, in Fig. 5 we give a schema that shows the main relations and concepts used in our theory of engineering functions.

Fig. 5.

Main concepts and relations in the presented ontology. For simplicity and clarity, the picture refers to the OWL model and many relations and concepts have been suppressed. In addition, an instantiation of the schema for the case of a voltage divider is given. The dotted instance-of arrow is inferrable, since the related systemic function is main-function-of some engineering method (cfr. (D24)).

We conclude this section with another example to show how the concepts we have introduced above concur to provide an integrated description of a functional scenario. Suppose that a company handling swimming pools must empty some of its pools for maintenance. This imposes a goal, say ‘the pools are empty’, that must be carried out through some device able to realize a ‘to move’ (ontological) function, specialized to a systemic function in the context of the swimming pool system. Such a function can be realized by artifacts that have a corresponding capability. In this case, the function would probably be implemented through some fluid-emptying-method, that is, through the knowledge of the way that a recipient can be emptied, and its fluid content disposed of, by pressurizing the fluid and guiding it through a path. Now, the ‘pressurize’ sub-function (which refers to the goal of ‘having a big enough pressure gradient’) could be implemented through a pumping-method, that is, referring to engineering knowledge about pumps. Then, a pump (more generally an artifact with pumping capability) could be selected for being the ‘doer’ of the necessary ‘transform electrical energy into pressure’ sub-sub-function. In this context, we could say that the pump has been selected because of its pumping-capability and that the pumping-method describes, at least, a flow rate capacity, which founds the pumping-capability, and its interaction to the other properties and entities involved in the pumping process.

6. Evaluation and possible applications

6.1. Reduction to OWL ontology

To facilitate the deployment of our theory in applications, we present an OWL version of the first-order logic formalization. This is standard practice, for at least the following reasons: first, OWL is decidable, while first-order logic is not, so that reasoning tasks will terminate in finite time.33

³³
Though the complexity might be exponential in general.

Second, OWL is a standard endorsed by the World Wide Web Consortium (W3C) and is part of the Semantic Web technology stack [102], and is the language of choice for many ontologies in various domains [75].

Unfortunately, the computational properties of OWL come with a tradeoff with respect to its expressibility, therefore, one has to simplify the first-order theory. The original theory remains essential as it constrains the intended meanings of the OWL concepts and provides the ‘official reading’ of the theory, it also helps to conceptually understand how the overall model is supposed to work.

The first-order theory developed in the previous sections can be converted to OWL language as is, except for the expressions where ternary relations are used, as well as those that necessarily need at least three arguments to be formulated. For example, the definition of systemic-function-of (d8), the instantiation-founding definition (d5), and the engineering method schema (d15) cannot be expressed in OWL. In these cases we have to weaken the axioms. For instance, in OWL we replace the definition of systemic functions with

${Function}_{Sys} ⊑ (\forall classifies . Behaviour ⊓ \exists causalContr . Goal) ⊓ \exists founded . System)$

where

classifies

is the inverse relation of

CF (\cdot, \cdot, \cdot)

. In this way the fact that systemic functions are founded on systems is preserved.

Additionally, all the ternary temporalized relations used in the first-order version, such as $CF (\cdot, \cdot, \cdot)$ and $participateAsDoer (\cdot, \cdot, \cdot)$ , occur in the OWL version with the temporal argument removed, i.e., as binary relations. The link between the temporalized and non-temporalized relations can be interpreted in different ways [95]. For example, one could state that the non-temporalized relation holds if and only if the temporalized relation holds whenever one of the relation arguments exists, what argument precisely depends on the relation. This is our choice for parthood (d7), classification, temporal quale, and participation-like relations as shown by these meta-rules aimed to show the intended interpretations:

$CF (x, y) ⟺ ((\exists t PRE (x, t)) \land \forall t (PRE (x, t) ⟹ CF (x, y, t)))$

“x is constantly classified by y if and only if x is classified by y whenever x exists”

$cql (x, y) ⟺ ((\exists t PRE (x, t)) \land \forall t (PRE (x, t) ⟹ ql (x, y, t)))$

“y is a constant temporary quale of the quality x if and only if y is a temporary quale of y whenever x exists”

$participatesAsDoer (x, y) ⟺ \exists t (PRE (y, t)) \land \forall t (PRE (y, t) ⟹ participatesAsDoer (x, y, t))$

“x constantly participates-as-doer to y if and only if x participates-as-doer to y for the whole of y duration”

One could also state that the non-temporalized relation holds if and only if the temporalized relation holds true at some time adopting the following meta-rule:

$participatesAsDoer (x, y) ⟺ \exists t participatesAsDoer (x, y, t)$

There are other possibilities. The choice of one over the others must be planned carefully depending on the application concerns, since this kind of changes affects the intended models of the OWL ontology. For example, (d21) excludes participation-as-doer in, say, a chemical process only for its first part, while (ex6) allows it, but in OWL this difference is lost. Additionally, the removal of the temporal argument reduces the flexibility of the ensuing ontology. For example, one cannot track (at least not directly) dynamic aspects of roles, e.g. a component that carries out a function at a time and then it changes its function. Nor one can express that, say, there is a chemical process which is driven by two different catalysts during its first and second parts.

Finally, as a further simplifying assumption, we define two binary relations that we will use as shortcuts to implement and simplify the definition schema (d15) and to redefine (d16):

$mainFunctionOf (f, m) ⟺ (SP (f, {main}^{m}) \land {Function}_{Sys} (f))$

“ $f$ is main-function-of a method $m$ if and only if it is a systemic function specializing the main-function role correspondig to $m$ ”

$subFunctionOf (f, m) ⟺ (SP (f, {sub}_{i}^{m}) \land {Function}_{Sys} (f))$

“ $f$ is main-function-of a method $m$ if and only if it is a systemic function specializing any of the sub-function roles correspondig to $m$ ”

${Function}_{Eng} \equiv \exists mainFunctionOf . {Method}_{Eng}$

“Engineering functions are exactly the individuals that are main-function-of some engineering method”

Note that in (d24) the individuals must necessarily be systemic functions due to (d22).

Even though the DOLCE ontology is primarily a first-order logic theory, OWL versions exist as well, e.g. DOLCE-lite and DOLCE-Ultralite.34

³⁴

Available at http://www.loa.istc.cnr.it/index.php/dolce/.

Any of these could be used to align the ontology developed in this paper with DOLCE. In our case, we used the OWL version of DOLCE that has been recently submitted as part the ISO 21838 standard. The resulting ontology, which can be found on GitHub,35

³⁵

https://github.com/kataph/function-method-ontology.git.

was tested using the Hermit reasoner. (For the sake of example, the ontology is populated with only a few individuals).

6.2. Evaluation

The ontology developed in this paper is a hand-crafted prototype that discusses middle and high-level concepts. Therefore, some common approaches to evaluation cannot be employed, as, for example, there is no “gold standard” [90], or set of formal ontologies that one could use to compare common ontology metrics (such as those extracted by OntoMetrics36

³⁶
https://ontometrics.informatik.uni-rostock.de/ontologymetrics/index.jsp.

), nor there is a precise application against which to carry out the evaluation. Instead, we will evaluate our ontology using the OntoClean methodology [35] and the Ontology Pitfall Scanner [79]. Moreover, we will discuss how our ontology answers the research questions (RQ1)–(RQ3), as well as some competency questions that will serve to demonstrate the expressive potential of the ontology. Finally, we will also discuss some possible application scenarios, though we highlight that the ontology main goals are the research questions (RQ1)–(RQ3). The development of derived application-level ontologies is a goal for further work.

OntoClean OntoClean does not identify any issue in our taxonomy, that is, none of the meta-level rules that OntoClean methodology enforces are violated. In fact, this is almost trivial to check: since we are extending DOLCE categories, the only source of OntoClean violations would be an extension of role-concepts (that is, the set of all entities that, at a given time, are classified by the role-concept) which is not anti-rigid. This condition is not violated since (systemic) functions, as we define them, are contextual (e.g., a heat exchanger, with its behaviour, may be used either to heat a substance or to cool it, depending on the context). The other rules checked in the OntoClean methodology are trivially true. The correspondence with OntoClean principles is mainly due to the alignment of our theory with a well-established upper-level ontology.

Ontology Pitfall Scanner The OWL ontology was evaluated with the Ontology Pitfall Scanner (OOPS!) [79], which searches for common design errors from a list of 41 items. Among the pitfalls not related to imported ontologies, the scanner found some minor stylistic issues37

³⁷

Some inverse object-properties are not declared explicitly, and the naming convention differs between object-properties and classes.

and warned about a few important pitfalls: P11 (“Missing domain or range in properties”), P24 (“Using recursive definitions”), and P30 (“Equivalent classes not explicitly declared”). Of these three, P11 means that not every object property has domain and range axioms, but this is a conscious design choice to reduce the ontological commitment of the ontology. P24 occurs because OOPS! thinks that (a13) is a recursive definition (since the class of ontological functions appears both on the left and on the right of the material implication), but this is not the case. Similarly, P30 occurs because OOPS! is, incorrectly, assuming that the class of resistors (capabilities) and the class of resistances (capacities) should be equivalent.

Research questions and competency questions Our ontology answers the research questions listed in the introduction. In particular:

Answer to (RQ1). We modeled functions as DOLCE-concepts that classify certain classes of perdurants. This modelling choice explains how functions can exist even when they are not executed. Moreover, we separated functions into the distinct categories of engineering methods and (proper) functions, and, further, we separated functions into systemic or ontological depending on their abstraction level, thus explaining the ambiguity on the why-how or abstraction-implementation axes.

Answer to (RQ2). Systemic functions can be decomposed as discussed in Section 4.3, where each decomposition is associated with an engineering method.

Answer to (RQ3). We have characterized capabilities and capacities in Section 5. In the first case we leveraged ontological functions, in the second case we suggested considering capacities as parameters of capabilities. Moreover, capabilities and capacities are clearly separated by the use of the founding relation: capabilities are founded on capacities, while the opposite does not hold.

Additionally, since the formal ontology answers these research questions, it is also able to answer related competency questions, which can be of interest in applications, such as the following:

Given an (ontological) function, which artifacts have the capability of satisfying it?

How can the given ontological function be implemented?

What are the capacities that a given capability is founded on?

Which parameters explain the performance of the some component in a given system? (If interpreted as ‘what are the capacities of the capabilities of the component that are relevant in executing its function?’)

Which is the functional decomposition of a given system?

Which is the function of the given tag and what is its purpose?

The OWL ontology, after being populated, can be used to answer the competency questions (CQ1)–(CQ6) by means of SPARQL queries. For example, these are implementations of (CQ1):

PREFIX : <https://github.com/kataph/function-method-ontology#> SELECT ?component WHERE { ?capability :definition-founded-on :<the given function> . ?capability :quality-of ?component}

of (CQ4):

PREFIX : <https://github.com/kataph/function-method-ontology#> SELECT ?component ?functionOntological ?capacity WHERE { ?functionSystemic :function-of ?component . ?functionSystemic :founded-on :<the given system> . ?functionSystemic :specializes ?functionOntological . ?capability :definition-founded-on ?functionOntological . ?capability :quality-of ?component . ?capability :founded-on ?capacity . ?capacity :quality-of ?component}

and of (CQ5), provided that the functional decomposition of a system is interpreted as the list of all systemic functions of the given system involved in a method, with their role (main-function or sub-function) and underlying component:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX : <https://github.com/kataph/function-method-ontology#> SELECT ?component ?functionSystemic ?role ?method WHERE { ?functionSystemic ?role ?method . ?method rdf:type/rdfs:subClassOf* :EngineeringMethod . ?functionSystemic :function-of ?component . ?component :constant-part-of :<the given system>}

The remaining competency questions can be implemented in a similar way (see also Fig. 6 for (CQ3), which is taken from the Protegé ontology editor – Fig. 7 shows another view of how the ontology appears in Protegé).

Fig. 6.

An implementation of (CQ3) in Protegé.

The fact that our ontology can answer all these questions shows its expressivity and coverage. In the following paragraphs we explain how these characteristics could be used in application scenarios.

Fig. 7.

A view of the ontology taxonomy in Protegé.

6.3. Motivating scenarios

Innovative design (and other things) A good portion of the literature on functional modelling argues that functional modelling can be used to improve engineering design. For instance, the basic argument of the approach of Pahl and [78] is as follows: designers should start from the customer’s requirements, translate them into high-level functions, then decompose those functions into less abstract ones, until arriving at a point where finding a solution that realizes the functions is easy. This methodology, is argued, facilitates engineers to quickly develop high-quality designs and enhances their creativity by decoupling the goals of the design from the ways they are achieved.

This argument is not wrong, but, in actual practice, one rarely starts from a blank slate. Designers are typically constrained by the need to reuse pre-existing solutions, for a company may have developed a legacy that is difficult to depart from, possibly because the company would not be able to (profitably) reroute its know-how and resources towards innovative lines of products, or other reasons. Therefore, designers usually have to devise marginal improvements or corrections in pre-existing solutions, and these activities seem at odds with the aforementioned methodology. Additionally, the described methodology is design-oriented and does not seem relevant to other activities, such as troubleshooting or reverse engineering, despite functional reasoning being clearly relevant in all of them.

One important reason for carrying out ontological analysis is to bridge all such activities and cases, by producing an explicit representation (the ontology) of the shared conceptualisation of the relevant stakeholders, which can be used by all of them. We argue that our ontology is useful for the blank-slate innovation scenario (for, e.g., competency questions (CQ1) and (CQ3) showcase the possibility of linking capabilities to functions, which is important since it allows engineers to find whether they already have available components that can satisfy a given functional requirement), as well as many other scenarios, some of which we describe briefly in the following.

Incremental innovation In a company, innovation may happen mainly through incremental changes in pre-existing products. Therefore, product types will have a version history. Using our ontology, one could describe the relevant improvements, allowing their digitalisation in a semantically meaningful way. For instance, a new version may introduce new capabilities, or it may have the same capabilities as the former version, but it could realize them better due to different capacities. Storing such information could be more helpful to engineers than just storing structural information (like the bill of material) of the different versions in the enterprise management system.

Knowledge transfer An engineer or technician could have recently been employed by a manufacturing company. In that case, he or she is (hopefully) trained to learn about the company’s products and their functioning. Still, a good part of the knowledge the company possesses, especially functional knowledge, is implicit. Therefore, the trainee will learn about it only through experience or through his/her background knowledge of the domain. This may be a slow process, and some knowledge could be lost. Building a knowledge base modelling functional knowledge (necessarily together with other types of information, e.g. geometrical from CAD models, etc.) could facilitate training since it would relieve the trainee from having to infer the functionality of components from their structure, as well as the (functional) role of components within their systems.

Troubleshooting When a technician troubleshoots a product he often makes use of functional reasoning (e.g., “the volume of the speakers is constantly louder than it should be. It may be that there is something wrong with the amplifier circuit, since it is that component that has the function of controlling the volume”). Sometimes, a technician may lack sufficient knowledge about the functional structure of a product to carry out such reasoning fruitfully (say, it is an external contractor with limited knowledge of the company which manufactures the product). In those cases, a clear representation of the product functional structure, if accessible to the technician, may solve the issue. For example, a query answering (CQ4) may be useful in this case.

Formal requirements Requirements are an essential part of engineering design, which engineers have to write, share, maintain, and implement. The ensuing work and documentation can be daunting, especially in large progects. Therefore, attempts have been made to standardize [1], trace [74], and automatize [38] requirement pipelines using ontologies. Some approaches discuss how requirements should be written, so that their quality, shareability, and even automatic verification against a design model can be assured (e.g., [18,58]). In the latter case, requirements are usually interpreted as assertions (constraints) about an engineering artifact that can be expressed (at least some of them can) in a formal language. The fact that the requirement refers to something that should be, and not to something that is, means that requirements are modal concepts, though this can be left implicit in formal representations. For example, a requirement translated directly from a client’s request, could be that the product, say a table, “must weight as little as possible”, then engineers could precise this in different ways, e.g., by stating

$weight (table_top) ⩽ 5 kg \land weight (i_{th}_table_leg) ⩽ 2 kg$ , for $i = 1, 2, 3, 4$ .

Therefore, if one also designs products using the same formal language, the products can be checked against the set of constraints, to verify that those are satisfied by the products.

One difficulty of this approach is that some requirements are more difficult to express than others. Requirements such as (ex7) are easy to express, as they refer to physical properties of the products (they are sometimes called “physical requirements” [58]). On the other hand, requirements linked to product performance or functions are more difficult to express. For example, in [58], the requirements “The artifact [desk spot lamp] should be able to illuminate more than half a square meter of room”, “The base [of the desk spot lamp] should provide support to the artifact”, and “the short arm must have a hole […]” are formalized as follows:

$arm (p) ⟹ \exists f (hole_feature (f) \land feature_of (f, p) \land [\dots]$ .

$desk_spot_lamp (p) ⟹ \exists f (illuminating_feature (f) \land feature_of (f, p) \land illumination_area (f) ⩾ 0.5$

$base (p) ⟹ \exists f (provide_support_feature (f) \land feature_of (f, p)$

Therefore, predicates “

illuminating_feature

”, “

provide_support_feature

”, and “

hole_feature

” are introduced to classify the capability to illuminate, the function to support, and the hole of the short arm as “

feature_of

” the corresponding artefacts. So that capabilities and functions are features in the same sense that a hole is, and we consider this an ontological error.38

³⁸
For example, in DOLCE features form a category of endurants that are (generically constantly) dependent on physical objects that cannot be detached from their corresponding physical object without losing their identities. In this sense, a hole is a feature, while the wheel of a car is not. The fact that, in our approach, features are not capabilities or functions, entailed by our categorisation of those as qualities and non-physical endurants, respectively.

The point is that being able to express requirements that mention capabilities or functions is difficult, and an ontology describing such concepts would make things easier. For example, using our theory we would write requirements (ex9) and (ex10) as, respectively (in the following we have introduced a subclass of capabilities, $illuminating_capability$ , a subclass of capacities $illumination_area$ , and a subclass of (ontological) functions, $provide_support$ ):

$desk_spot_lamp (p) ⟹ \exists f, c, v (illuminating_capability (f) \land qt (f, p) \land illumination_area (c) \land founded (f, c) \land cql (c, v) \land CP (v, [0.5, \infty))$

“Every desk spot lamp has a capability to illuminate, founded on an illumination-area-capacity greater than 0.5”

$base (p) ⟹ \exists f_{o}, f_{s} (provide_support (f_{o}) \land CF (f_{s}, f_{o}) \land {FunctionOf}_{Sys} (f_{s}, p))$

“Every lamp base has a (systemic) function of (ontological-function-)type provide support”

Notice that (ex11) and (ex12) can be readily rewritten in OWL, so that they can be part of an OWL knowledge base containing all the requirements that can be expressed in a similar way. Then, if engineers build during design a model of the product, using the same language, they just need to import the model into the knowledge base with the requirements: the product model satisfies the requirements if and only if the ensuing ontology is consistent (similarly one can find if the requirements are inconsistent or if there are duplicates). In an actual application the user may never write complex formulas such as (ex11) and (ex12), unless user-friendly templates are made available as done in [18].

An analogous procedure is the one that the READI project [51,77] aims to implement. In their case, the requirement are expressed in SCD (Scope Condition Demand) form. This means that they are assertions of the form

$S ⊓ C ⊑ D$

where S, C, and D are OWL classes, for example (the example is taken from [77]), “Equipment with a transport dry weight above 1000 kg shall be weighed by the manufacturer and a weight certificate shall be issued” is written in such a form, if S, C, and D are interpreted as the classes ‘Equipment’, ‘things with transport dry weight above 1000 kg’, ‘things that have a weight certificate’, respectively. Again, it is difficult to express functions- and performance-related requirements in the format of (ex13) if one lacks an appropriate reference ontology.

7. Conclusion

The work presented in this paper contributes to the ontological understanding and modeling of fundamental concepts used in engineering, especially functionality. In particular, we have shown how one can give ontologically-grounded definitions of capability, capacity, behaviour, and function using first-order logic. Moreover, we have shown how one can use an ontology and the notion of functional decomposition to distinguish between ontological, systemic, and engineering functions, and how ontological functions can be used to explain the difference between capabilities and capacities. Finally, we partially translated our first-order theory in OWL, showcasing a preliminary serialisation of our theory in a computer-friendly formal language.

Our approach builds on a series of previous works, especially on the study of functionality carried out by engineers and researchers, in particular [71,78,87]; the study of resources in manufacturing, in the applied ontology literature as well as some standards [11,39,84]; and the top-level ontology DOLCE and its developments [7,65,66]. This work relies on an in-depth ontological analysis of the domain, which, exploiting the characteristics of the DOLCE ontology, clarifies the conceptualisation of functions and related concepts in a systematic way.

We evaluated the quality of our implementation by assessing the clarity, expressive capability, and flexibility of our ontology with respect to some research questions, some competency questions, and some application scenarios. The relevance of our work is highlighted by the ability to answer a series of questions, from (RQ1)–(RQ3) to (CQ1)–(CQ6), showing that the ontology could be able to support applications in most engineering scenarios where functional reasoning is required.

This paper has set the vision and the core elements of our theory, yet many things require further work and testing to achieve a level of detail and coverage suitable for real applications. For example, linking the notions of behaviour to the modelling equations that engineers use to simulate a system is a topic that has not been addressed and requires additional research. Similarly, we need to analyze more in-depth how an ontological approach based on our theory can help to make uniform the description of application scenarios, starting from those touched upon in the paper.

Footnotes

Acknowledgements

The authors acknowledge support by the European project OntoCommons (GA 958371, ). Francesco Compagno is funded by the company Adige Spa. The authors wish to thank Riichiro Mizoguchi for the precious time spent discussing his work as well as the topics of function definition and engineering function modelling.

References

Alrumaih,

Mirza and

Alsalamah, Domain ontology for requirements classification in requirements engineering context, IEEE Access8 (2020), 89899–89908. doi:10.1109/ACCESS.2020.2993838.

Arp and

Barry, Function, role and disposition in basic formal ontology, in: Nature Precedings, 2008.

Artiga, New perspectives on artifactual and biological functions, Appl. Ontology11(2) (2016), 89–102. doi:10.3233/AO-160166.

Borgo,

Carrara,

Garbacz and

P.E.

Vermaas, A formal ontological perspective on the behaviors and functions of technical artifacts, Artificial Intelligence for Engineering Design, Analysis and Manufacturing23(1) (2009), 3–21.

Borgo,

Carrara,

Garbacz and

P.E.

Vermaas, A formalization of functions as operations on flows, Journal of Computing and Information Science in Engineering11(3) (2011), 031007. doi:10.1115/1.3615523.

Borgo,

Cesta,

Orlandini and

Umbrico, Knowledge-based adaptive agents for manufacturing domains, Engineering with Computers35(3) (2019), 755–779. doi:10.1007/s00366-018-0630-6.

Borgo,

Ferrario,

Gangemi,

Guarino,

Masolo,

Porello,

E.M.

Sanfilippo and

Vieu, DOLCE: A descriptive ontology for linguistic and cognitive engineering, Applied Ontology17(1) (2022), 45–69. doi:10.3233/AO-210259.

Borgo,

Franssen,

Garbacz,

Kitamura,

Mizoguchi and

P.E.

Vermaas, Technical artifacts: An integrated perspective, Applied Ontology9(3–4) (2014), 217–235. doi:10.3233/AO-140137.

Borgo and

Leitao, Foundations for a core ontology of manufacturing, in: Ontologies. A Handbook of Principles, Concepts and Applications in Information Systems,

R.R.R.

Sharman and

Kishore, eds, Springer US, 2007, pp. 751–775. doi:10.1007/978-0-387-37022-4_27.

10.

Borgo and

Mizoguchi, A first-order formalization of event, object, process and role in YAMATO, in: International Conference on Formal Ontology in Information Systems (FOIS 2014), FAIA, Vol. 267, IOS Press, 2014, pp. 79–92.

11.

Borgo,

E.M.

Sanfilippo and

Terkaj, Capabilities, capacities, and functionalities of resources in industrial engineering, in: CEUR Workshop Proceedings, Bolzano, Italy, 2021, p. 12.

12.

D.C.

Brown and

Blessing, The relationship between function and affordance, in: Volume 5a: 17th International Conference on Design Theory and Methodology, ASMEDC, Long Beach, California, USA, 2005, pp. 155–160. doi:10.1115/DETC2005-85017.

13.

Burek,

Hoehndorf,

Loebe,

Visagie,

Herre and

Kelso, A top-level ontology of functions and its application in the open biomedical ontologies, Bioinformatics22(14) (2006), e66–e73. doi:10.1093/bioinformatics/btl266.

14.

Burek,

Loebe and

Herre, Overview of GFO 2.0 functions: An ontology module for representing teleological knowledge, Procedia Computer Science192 (2021), 1021–1030. doi:10.1016/j.procs.2021.08.105.

15.

Campbell, Abstract Particulars, Basil Blackwell, Oxford, 1990.

16.

Chandrasekaran,

A.K.

Goel and

Iwasaki, Functional representation as design rationale, Computer26(1) (1993), 48–56. doi:10.1109/2.179157.

17.

Chandrasekaran and

J.R.

Josephson, Function in device representation, Engineering with Computers16(3–4) (2000), 162–177. doi:10.1007/s003660070003.

18.

Chen,

C.-H.

Chen,

Liu and

Ye, Ontology-based requirement verification for complex systems, Advanced Engineering Informatics46 (2020), 101148. doi:10.1016/j.aei.2020.101148.

19.

J.A.

Collins,

B.T.

Hagan and

H.M.

Bratt, The failure-experience matrix – a useful design tool, Journal of Engineering for Industry98(3) (1976), 1074–1079. doi:10.1115/1.3439009.

20.

Cummins, Functional analysis, The Journal of Philosophy72(20) (1975), 741–765. doi:10.2307/2024640.

21.

De Kleer, How circuits work, Artificial Intelligence24(1–3) (1984), 205–280.

22.

De Kleer and

J.S.

Brown, A qualitative physics based on confluences, 1984, 78.

23.

M.S.

Erden,

Komoto,

T.J.

van Beek,

D’Amelio,

Echavarria and

Tomiyama, A review of function modeling: Approaches and applications, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 22(2) (2008), 147–169.

24.

C.M.

Fonseca,

Porello,

Guizzardi,

J.P.A.

Almeida and

Guarino, Relations in ontology-driven conceptual modeling, in: Conceptual Modeling,

A.H.F.

Laender,

Pernici,

E.-P.

Lim and

J.P.M.

de Oliveira, eds, Vol. 11788, Springer International Publishing, Cham, 2019, pp. 28–42. doi:10.1007/978-3-030-33223-5_4.

25.

Garbacz,

Borgo,

Carrara and

P.E.

Vermaas, Two ontology-driven formalisations of functions and their comparison, Journal of Engineering Design22(11–12) (2011), 733–764. doi:10.1080/09544828.2011.597376.

26.

Gärdenfors, Conceptual Spaces: The Geometry of Thought, MIT Press, 2004.

27.

J.S.

Gero, Categorising technological knowledge from a design methodological perspective, in: International Conference on Technological Knowledge: Philosophical Reflections, Boxmeer, the Netherlands, 2002.

28.

J.S.

Gero and

Kannengiesser, The situated function–behaviour–structure framework, Design Studies25(4) (2004), 373–391. doi:10.1016/j.destud.2003.10.010.

29.

J.J.

Gibson, The theory of affordances, in: The Ecological Approach to Visual Perception, Houghton Mifflin, Boston, 1979.

30.

A.S.

Gill and

Sen, Logic rules for automated synthesis of function models using evolutionary algorithms, in: Volume 2: 41st Computers and Information in Engineering Conference (CIE), American Society of Mechanical Engineers, Virtual, Online, 2021.

31.

A.K.

Goel and

S.R.

Bhatta, Use of design patterns in analogy-based design, Advanced Engineering Informatics18(2) (2004), 85–94. doi:10.1016/j.aei.2004.09.003.

32.

A.K.

Goel,

Rugaber and

Vattam, Structure, behavior, and function of complex systems: The structure, behavior, and function modeling language, Artificial Intelligence for Engineering Design, Analysis and Manufacturing23(1) (2009), 23–35.

33.

Guarino,

Baratella and

Guizzardi, Events, their names, and their synchronic structure, Applied Ontology17(2) (2022), 249–283. doi:10.3233/AO-220261.

34.

Guarino and

Welty, A formal ontology of properties, in: Knowledge Engineering and Knowledge Management Methods, Models, and Tools,

Goos,

Hartmanis,

van Leeuwen,

Dieng and

Corby, eds, Vol. 1937, Springer Berlin Heidelberg, Berlin, Heidelberg, 2000, pp. 97–112. doi:10.1007/3-540-39967-4_8.

35.

Guarino and

C.A.

Welty, An overview of OntoClean, in: Handbook on Ontologies,

Staab and

Studer, eds, Springer Berlin Heidelberg, Berlin, Heidelberg, 2009, pp. 201–220. doi:10.1007/978-3-540-92673-3_9.

36.

Herre,

Heller,

Burek,

Hoehndorf,

Loebe and

Michalek, General formal ontology (GFO) – a foundational ontology integrating objects and processes [version 1.0], Technical report, 8, Institute of Medical Informatics, Statistics and Epidemiology (IMISE), 2006.

37.

Hirtz,

R.B.

Stone,

D.A.

McAdams,

Szykman and

K.L.

Wood, A functional basis for engineering design: Reconciling and evolving previous efforts, Research in Engineering Design13(2) (2002), 65–82. doi:10.1007/s00163-001-0008-3.

38.

O.M.

Holter and

Ell, Towards scope detection in textual requirements, in: 3rd Conference on Language, Data and Knowledge (LDK 2021), Open Access Series in Informatics (OASIcs), Vol. 93, 2021, p. 15, https://drops.dagstuhl.de/opus/volltexte/2021/14567 .

39.

ISO, ISO 15531-31: Industrial automation systems and integration – industrial manufacturing management data – part 31: Resource information model, Industrial Manufacturing Management Data, 2004.

40.

Jansen, Functions, malfunctioning, and negative causation, in: Philosophy of Science,

Christian,

Hommen,

Retzlaff and

Schurz, eds, Vol. 9, Springer International Publishing, Cham, 2018, pp. 117–135. doi:10.1007/978-3-319-72577-2_7.

41.

Järvenpää,

Siltala,

Hylli and

Lanz, The development of an ontology for describing the capabilities of manufacturing resources, Journal of Intelligent Manufacturing30(2) (2019), 959–978. doi:10.1007/s10845-018-1427-6.

42.

A.M.

Keuneke, Device representation – the significance of functional knowledge, IEEE Expert6(2) (1991), 22–25. doi:10.1109/64.79705.

43.

Kitamura,

Koji and

Mizoguchi, An ontological model of device function: Industrial deployment and lessons learned, Applied Ontology1(3–4) (2006), 237–262.

44.

Kitamura and

Mizoguchi, Meta-functions of artifacts, in: Proc. of the Thirteenth International Workshop on Qualitative Reasoning (QR-99), Loch Awe, Scotland, 1999, pp. 136–145.

45.

Kitamura and

Mizoguchi, Ontology-based description of functional design knowledge and its use in a functional way server, Expert Systems with Applications24(2) (2003), 153–166. doi:10.1016/S0957-4174(02)00138-0.

46.

Kitamura and

Mizoguchi, Ontology-based functional-knowledge modeling methodology and its deployment, in: Engineering Knowledge in the Age of the Semantic Web,

Motta,

N.R.

Shadbolt,

Stutt and

Gibbins, eds, Vol. 3257, Springer Berlin Heidelberg, Berlin, Heidelberg, 2004, pp. 99–115. doi:10.1007/978-3-540-30202-5_7.

47.

Kitamura and

Mizoguchi, Ontology-based systematization of functional knowledge, Journal of Engineering Design15(4) (2004), 327–351. doi:10.1080/09544820410001697163.

48.

Kitamura and

Mizoguchi, Characterizing functions based on phase- and evolution-oriented models, Applied Ontology8(2) (2013), 73–94. doi:10.3233/AO-130123.

49.

Kitamura,

Sano,

Namba and

Mizoguchi, A functional concept ontology and its application to automatic identification of functional structures, Advanced Engineering Informatics16(2) (2002), 145–163. doi:10.1016/S1474-0346(02)00006-X.

50.

Kitamura,

Segawa,

Sasajima,

Tarumi and

Mizoguchi, Deep semantic mapping between functional taxonomies for interoperable semantic search, in: The Semantic Web,

Domingue and

Anutariya, eds, Vol. 5367, Springer Berlin Heidelberg, Berlin, Heidelberg, 2008, pp. 137–151. doi:10.1007/978-3-540-89704-0_10.

51.

J.W.

Klüwer, Ontology-based requirements management – presentation at SemWeb.Pro 2018, November 6 2018, Paris (2018), 29.

52.

J.W.

Klüwer,

Martin-Recuerda,

Waaler,

Lupp,

M.M.

Brandt,

Grimm,

Koleva,

Khan,

Hella and

Sandsmark, ISO 15926-14:2020(E), Working draft, READI, 2020.

53.

Köcher,

Belyaev,

Hermann,

Bock,

Meixner,

Volkmann,

Winter,

Zimmermann,

Grimm and

Diedrich, A reference model for common understanding of capabilities and skills in manufacturing, arXiv, 2022.

54.

Kocher,

Hildebrandt,

L.M.

Vieira da Silva and

Fay, A formal capability and skill model for use in plug and produce scenarios, in: 2020 25th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), IEEE, Vienna, Austria, 2020, pp. 1663–1670. doi:10.1109/ETFA46521.2020.9211874.

55.

Kurtoglu,

Swantner and

M.I.

Campbell, Automating the conceptual design process: “From black box to component selection”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing24(1) (2010), 49–62. doi:10.1017/S0890060409990163.

56.

Kurtoglu and

I.Y.

Tumer, A graph-based fault identification and propagation framework for functional design of complex systems, Journal of Mechanical Design130(5) (2008), 051401. doi:10.1115/1.2885181.

57.

J.E.

Larsson, Diagnosis based on explicit means-end models, Artificial Intelligence80(1) (1996), 29–93. doi:10.1016/0004-3702(94)00043-3.

58.

Lin,

M.S.

Fox and

Bilgic, A requirement ontology for engineering design, Concurrent Engineering4(3) (1996), 279–291. doi:10.1177/1063293X9600400307.

59.

Loebe, Abstract vs. social roles – towards a general theoretical account of roles, Applied Ontology2 (2007), 127–158.

60.

J.H.

Lugo Calles,

Ramadoss,

Zoppi,

Cannata and

Molfino, Modeling of a cable-based revolute joint using biphasic media variable stiffness actuation, 2019. doi:10.1109/IRC.2019.00125.

61.

J.R.

Maier and

G.M.

Fadel, Affordance: The fundamental concept in engineering design, in: International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, Vol. 80258, American Society of Mechanical Engineers, 2001, pp. 177–186.

62.

J.R.A.

Maier and

G.M.

Fadel, Affordance based design: A relational theory for design, Research in Engineering Design20(1) (2009), 13–27. doi:10.1007/s00163-008-0060-3.

63.

Malzkorn, Defining disposition concepts: A brief history of the problem, Studies in History and Philosophy of Science Part A32(2) (2001), 335–353. doi:10.1016/S0039-3681(00)00042-X.

64.

Marshall and

Weatherson, Intrinsic vs. extrinsic properties, in: The Stanford Encyclopedia of Philosophy, Spring 2018 edn,

E.N.

Zalta, ed., Metaphysics Research Lab, Stanford University, 2018.

65.

Masolo,

Borgo,

Gangemi,

Guarino and

Oltramari, WonderWeb Deliverable D18, IST Project 2001-33052 WonderWeb: Ontology infrastructure for the semantic web, 2003.

66.

Masolo,

Vieu,

Bottazzi,

Catenacci,

Ferrario,

Gangemi and

Guarino, Social roles and their descriptions, in: Principles of Knowledge Representation and Reasoning: Proceedings of the Ninth International Conference (KR2004), Whistler, Canada, 2004, p. 11.

67.

McGinn, The ontology of energy, in: Basic Structures of Reality, Oxford University Press, New York, 2012.

68.

Mizoguchi, YAMATO: Yet another more advanced top-level ontology, http://www.hozo.jp/onto_library/upperOnto.htm.

69.

Mizoguchi and

Borgo, The role of the systemic view in foundational ontologies, in: The Joint Ontology Workshops (JOWO), 2021, p. 11.

70.

Mizoguchi,

Kitamura and The Hegeler Institute, A functional ontology of artifacts, Monist92(3) (2009), 387–402.

71.

Mizoguchi,

Kitamura and

Borgo, A unifying definition for artifact and biological functions, Applied Ontology11(2) (2016), 129–154. doi:10.3233/AO-160165.

72.

Mizoguchi and

Toyoshima, YAMATO: Yet another more advanced top-level ontology with analysis of five examples of change, in: Proceedings of FOUST II: 2nd Workshop on Foundational Ontology, CEUR-WS.org, Bozen-Bolzano, Italy, 2017, p. 13.

73.

Mota, Dispensing with the theory (and philosophy) of affordances, Theory & Psychology31(4) (2021), 533–551. doi:10.1177/0959354320980534.

74.

M.S.

Murtazina and

T.V.

Avdeenko, An ontology-based approach to support for requirements traceability in agile development, Procedia Computer Science150 (2019), 628–635. doi:10.1016/j.procs.2019.02.044.

75.

Ontology repositories, Technical report, https://www.w3.org/wiki/Ontology_repositories.

76.

Ortmann and

Kuhn, Affordances as qualities, in: Formal Ontology in Information Systems, IOS Press, 2010, pp. 117–130.

77.

P.Ø.

Øverli,

Saltvedt,

Ingebrigtsen,

J.K.

Slettebakk,

B.R.

Ydstebø,

Karlsen,

K.K.

Johan,

M.G.

Skjæveland and

M.O.

Knædal, Asset information modelling framework (IMF), Technical report, release 1, 2021.

78.

Pahl,

Beitz,

Feldhusen and

K.H.

Grote, Engineering Design: A Systematic Approach, 3rd edn, Springer, London, 2007.

79.

Poveda-Villalón,

Gómez-Pérez and

M.C.

Suárez-Figueroa, OOPS! (OntOlogy pitfall scanner!): An on-line tool for ontology evaluation, International Journal on Semantic Web and Information Systems (IJSWIS)10(2) (2014), 7–34. doi:10.4018/ijswis.2014040102.

80.

Qian and

J.S.

Gero, Function–behavior–structure paths and their role in analogy-based design, artificial intelligence for engineering design, Analysis and Manufacturing10(4) (1996), 289–312.

81.

Röhl and

Jansen, Why functions are not special dispositions: An improved classification of realizables for top-level ontologies, Journal of Biomedical Semantics5(1) (2014), 27. doi:10.1186/2041-1480-5-27.

82.

Roth, Konstruieren mit Konstruktionskatalogen, Springer Berlin Heidelberg, Berlin, Heidelberg, 2000.

83.

E.M.

Sanfilippo,

Benavent,

Borgo,

Guarino,

Troquard,

Romero,

Rosado,

Solano,

Belkadi and

Bernard, Modeling manufacturing resources: An ontological approach, in: Product Lifecycle Management to Support Industry 4.0 – 15th IFIP WG 5.1 International Conference, PLM 2018, Turin, Italy, July 2–4, 2018, Proceedings, 2018, pp. 304–313.

84.

E.M.

Sanfilippo,

Terkaj and

Borgo, Resources in manufacturing, in: Formal Ontologies Meet Industry, 2015, pp. 1–12.

85.

E.M.

Sanfilippo,

Terkaj and

Borgo, Ontological modeling of manufacturing resources, Applied Ontology16(1) (2021), 87–109. doi:10.3233/AO-210242.

86.

Sarkar and

Šormaz, Ontology model for process level capabilities of manufacturing resources, Procedia Manufacturing39 (2019), 1889–1898. doi:10.1016/j.promfg.2020.01.244.

87.

Sasajima,

Kitamura,

Ikeda and

Mizoguchi, FBRL: A function and behavior representation language, in: Proceedings of the Fourteenth International Joint Conference on Artificial Intelligence, Vol. 2, Montreal, Quebec, Canada, 1995.

88.

Sasajima,

Kitamurat,

Ikeda,

Yoshikawa,

Endou and

Mizoguchi, An investigation on domain ontology to represent functional models, in: Proceedings of Eighth International Workshop on Qualitative Reasoning About Physical Systems (QR 94), 1994, p. 10.

89.

Sembugamoorthy and

Chandrasekaran, Functional representation of devices and compilation of diagnostic problem-solving systems, in: Experience, Memory and Reasoning, 1986, pp. 47–73.

90.

Sfar,

A.H.

Chaibi,

Bouzeghoub and

H.B.

Ghezala, Gold standard based evaluation of ontology learning techniques, in: Proceedings of the 31st Annual ACM Symposium on Applied Computing, ACM, Pisa Italy, 2016, pp. 339–346. doi:10.1145/2851613.2851843.

91.

Shapiro and

Kouri Kissel, Classical logic, in: The Stanford Encyclopedia of Philosophy, Spring 2021 edn,

E.N.

Zalta, ed., Metaphysics Research Lab, Stanford University, 2021.

92.

Solano,

Rosado and

Romero, Knowledge representation for product and processes development planning in collaborative environments, International Journal of Computer Integrated Manufacturing27(8) (2014), 787–801. doi:10.1080/0951192X.2013.834480.

93.

D.A.

Spear,

Werner and

Barry, Functions in basic formal ontology, Applied Ontology11(2) (2016), 103–128. doi:10.3233/AO-160164.

94.

R.B.

Stone and

K.L.

Wood, Development of a functional basis for design, Journal of Mechanical Design122(4) (2000), 359–370. doi:10.1115/1.1289637.

95.

Terkaj,

Borgo and

E.M.

Sanfilippo, Ontology for industrial engineering: A DOLCE compliant approach, in: Formal Ontologies Meet Industry, 2022, pp. 1–13.

96.

Umeda,

Takeda,

Tomiyama and

Yoshikawa, Function, behaviour, and structure, in: Applications of Artificial Intelligence in Engineering, Vol. 1, 1990, pp. 177–193.

97.

VDI 2860: Assembly and handling; handling functions, handling units; terminology, definitions and symbols, Technical report, Verein Deutscher Ingenieure, 1990.

98.

Vermaas,

Eck and

Kroes, The conceptual elusiveness of engineering functions: A philosophical analysis, Philosophy & Technology26 (2013), 159–185. doi:10.1007/s13347-012-0096-1.

99.

Vermaas and

Garbacz, Functional decomposition and mereology in engineering, in: Philosophy of Technology and Engineering Sciences, Elsevier, 2009, pp. 235–271.

100.

P.E.

Vermaas, On the formal impossibility of analysing subfunctions as parts of functions in design methodology, Research in Engineering Design24(1) (2013), 19–32. doi:10.1007/s00163-012-0133-1.

101.

P.E.

Vermaas and

Dorst, On the conceptual framework of John Gero’s FBS-model and the prescriptive aims of design methodology, Design Studies28(2) (2007), 133–157. doi:10.1016/j.destud.2006.11.001.

102.

W3C Recommendation, OWL 2 web ontology language quick reference guide, Technical report, 2012. http://www.w3.org/TR/owl2-quick-reference/.

103.

S.-C.

Yang,

Patil and

Dutta, Function semantic representation (FSR): A rule-based ontology for product functions, Journal of Computing and Information Science in Engineering10(3) (2010), 031001. doi:10.1115/1.3462927.

104.

Zhao,

Chen,

Chen and

Xie, A state–behavior–function model for functional modeling of multi-state systems, Proceedings of the Institution of Mechanical Engineers, Part C: Journal of Mechanical Engineering Science233(7) (2019), 2302–2317. doi:10.1177/0954406218791640.

Towards a formal ontology of engineering functions,behaviours,and capabilities

Abstract

Keywords

1. Introduction

1 For example, the use of gearboxes made in a certain way in order to increase or reduce angular velocity, and a brushless electric motor as a way to convert electric energy to torque.

5 They explicitly exclude static behaviours such as supporting, though.

14 See Fig. 1 for a complete taxonomy.

22 See [8] for a more in-depth discussion of technical artifacts.

23 Note that the term ‘processual role’ refers to general perdurants, it is not limited to DOLCE processes. The terminology is taken from Loebe which introduces it relatively to the GFO approach [59].

27 We borrow the term from Vermaas and Garbacz [99], in there the interested reader can find a discussion about mereology in functional decomposition, especially with respect to the Functional Basis methodology.

31 As mentioned earlier in the paper, a clear-cut example is the voltage, which, since it is a potential, needs a fixed reference point in order to be measured.

32 An alternative is to model them as disposition, see for instance [86], and [63] for a broader introduction to dispositions.

6.1. Reduction to OWL ontology

33 Though the complexity might be exponential in general.

36 https://ontometrics.informatik.uni-rostock.de/ontologymetrics/index.jsp.

Footnotes

Acknowledgements

References

¹
For example, the use of gearboxes made in a certain way in order to increase or reduce angular velocity, and a brushless electric motor as a way to convert electric energy to torque.

⁵
They explicitly exclude static behaviours such as supporting, though.

¹⁴
See Fig. 1 for a complete taxonomy.

²²
See [8] for a more in-depth discussion of technical artifacts.

²³
Note that the term ‘processual role’ refers to general perdurants, it is not limited to DOLCE processes. The terminology is taken from Loebe which introduces it relatively to the GFO approach [59].

²⁷
We borrow the term from Vermaas and Garbacz [99], in there the interested reader can find a discussion about mereology in functional decomposition, especially with respect to the Functional Basis methodology.

³¹
As mentioned earlier in the paper, a clear-cut example is the voltage, which, since it is a potential, needs a fixed reference point in order to be measured.

³²
An alternative is to model them as disposition, see for instance [86], and [63] for a broader introduction to dispositions.

³³
Though the complexity might be exponential in general.

³⁶
https://ontometrics.informatik.uni-rostock.de/ontologymetrics/index.jsp.