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

This paper is an in-depth piece of (formal) ontological analysis on the notions of engineering functions, behaviors and capabilities.

The authors provide a detailed review of the literature in this area, which is rather rich with diverging understandings for the notions examined.

They approach the problem by reusing DOLCE, with a focus on its notions of quality (particularized property) (intrinsic and relational), roles, dependence, foundation, perdurants (and their categories).

The paper has a number of (credible) examples. But the formalization is rather weak, not providing full characterizations of the main notions analyzed (quite differently from the foundational ontology employed.)

For example, in the analysis of behavior: the authors introduce two forms of participation using predicates participatesAsDoer and participatesAsFlow. But these are not fully characterized/defined and are key to the formalization of "Behaviour" in a8. (participatesAsFlow is not characterized formally.)

(By the way, a8's explanation reads with "if and only if" but a8 has a single conditional. So, it's not clear whether we have a definition for "Behaviour".)

In the analysis of functions, we get a distinction between systemic functions, ontological functions and engineering functions. Systemic functions are clearly defined.

Ontological functions, differently from systemic functions, are not fully characterized. We learn that they are specialized by systemic functions and there is some informal intuition that they are in a sense more abstract and system-independent. (Why use the "ontological" modification for function? This is so neutral and to me conveys no intuition with respect to the intended usage.)

Capacities are also only partially characterized.

Capabilities are characterized by example, and then later defined by using capacities and ontological functions, which in their turn were only partially characterized. Hence capabilities are also only partially characterized.

Overall, the relevance/motivation for the detailed analysis work is not provided to the reader, and the formalization as is cannot be used for formal analysis/theorem proving (and is not used in this way in the paper).

The derived OWL implementation is not used in a concrete application, it is only used to exemplify the kinds of queries that a conforming knowledge base could support.

In terms of related work, it covers a lot of ground. I found that it covers BFO-related work quite superficially, and does not engage with Ludger Jansen et al.'s work [1].

The authors should clarify the relevance of their work to the readership; provide evidence for the quality of the formalization -- which seems to have too many gaps in its current form; and perform some form of assessment of the implementation as well (beyond absence of contradiction).

The paper is very well-written and I just found minor typos:

p.2 line 42, "toMantain" should read "toMaintain".

p.3 lines 23-24, missing closing parenthesis.

p.3 lines 24-25, missing comma after [25].

p.3 line 27-28, "of an engineering systems"

p. 13 line 9-10 "the" is probably "them"

[1] https://scholar.google.com/citations?hl=en&user=SRZpXjUAAAAJ

OWL implementation is available on GitHub.

The paper introduces an ontological description of functions, behavior, capability, and capacity. The proposal extends DOLCE ontology.
The article clearly describes the concepts in natural language, formalizes them using first-order logic, and then implements these formalizations using OWL.
Although many proposals define functions, the approach that is introduced in the article is original and is well ontologically founded.
An interesting issue of the article is that its formalization allows the implementation of the concepts so they can be used in practice.
The proposal is general enough to specialize in several domains in a straight fashion.
The article is well organized, and the quality of writing allows the reader to understand the proposal.
The authors provide an access to a Github repository with the proposed ontology. It is complete to replicate the queries introduced in the article (I have some problems running the first query).

The authors have done very good work in analyzing different perspectives of functions and related concepts in engineering design, and presenting their own contributions in formalizing those notions. This is an important topic in engineering design that could definitely need help from the ontology and Semantic Web communities, as exemplified by the current work. Based on this merit, I think the work is worthy enough for publication. However, I have a few suggestions for improvement as follows. I'd especially request the authors to consider the last point made in this review.

I have an issue with the phrase "systemic functions" because the term "system" is also a very broadly used term that is not easy to define nor formalize (as the authors also recognize later on). Hence, by including this term as part of the phrase, the authors are adding more ambiguity. Could the authors think of an alternative phrase? Otherwise, does a screw (typically not considered as a system) not have a "systemic function"?

I quite enjoyed reading the literature review -- it is not simply a cursory review of the prior work but highlights the subtle differences between all the prior work and sets up nicely for the work presented by the authors. However, I suggest a couple of improvements:

1. Another important related notion to functions besides capabilities is "affordance" in engineering design (see Maier and Fadel's work). The authors should provide some literature review and discussion on this topic, and preferably incorporate the analysis of this notion in their work.

2. While BFO may lack axiomatization of functions, Barry Smith has a number of papers on functions that are worth reviewing here. How does BFO's perspective on functions differ from the authors?

In Section 3, the authors should justify why DOLCE was chosen as the top-level ontology. Also, an introductory paragraph of why the three concepts (qualities, perdurants, and roles) are related to functions would be beneficial for the reader to follow along with the details of each concept presented.

I don't think color is a good example of intrinsic qualities because it is measured indirectly using light and is still a contentious topic for ontological debates. One could argue that there is no color if there is no light, the same as there is no weight if there is no gravity. Why not stick to more obvious examples of physical or material properties?

The analysis of behavior and the justification given to classify it as a perdurant was very well done. The section also leads to an important discussion on states and state variables. I wonder if the authors could expand or elucidate the definitions of behaviors using these notions. The reviewer (with an engineering background) assumes that most engineers model physical behaviors with equations and the values of their variables determine a particular state. They then use these equations to analyze or predict how well the artifact would realize its functional requirements. I think if the authors could bridge these notions (behaviors, states, and modeling equations), it could be another important contribution of the paper.

I wonder if the distinction between ontological and systemic functions is simply prescribed vs. actual (realized) functions. I'd like to hear the authors' thoughts.

I'm a bit concerned that the notion of requirements is not discussed anywhere in the paper, especially in Section 4. In practice, engineers deal with requirements more than functions. Could the authors discuss or define how they are related?

Understanding that OWL has limited expressiveness, why did the authors choose OWL to implement their ontology? Provide some justification in the paper.

There is a bit of irony in the engineering design practice regarding functions. While many people in academia emphasize the importance of functional modeling and decomposition and teach their students related methods, almost no one in the industry practices them. In fact, most design practices do not start from a blank state where desired functions are thought out, but rather with an initial design from which to improve. I wonder if the authors have thought about how their efforts could resolve this issue or help in any way. One could perform this type of work for the sake of formalizing "functions" and related notions, but for what practical benefits does it serve? How do the authors envision that their work could actually improve the engineering design practice? Can the authors identify any use cases, motivating scenarios, or competency questions that their ontology could address in real engineering design practices? I believe this should be addressed to make this type of work much more meaningful and significant to the engineering community.