Directly deriving binary relation types from concept types, especially process or role types

The article proposes a particular ontology design pattern (ODP)/ best practice, namely the idea of deriving binary relations in an ontology from concepts/classes, such as kinds of processes or roles. An example would be a relation which describes who is involved in an action, which can be derived from statements about the fillers of participation roles in a particular action. The authors suggest a set of derivation rules as well as concepts suitable for derivation expressed in the language of RIF FLD PR. They compare their suggestion with patterns on the ODP repository ODPC, and argue that many of the currently available ODPs could be derived based on the suggested approach.

The core idea of the authors has potential, even though it is not new: Namely to logically relate patterns in a type hierarchy based on derivations, in order to avoid redundancy, increase the flexibility and translatability of patterns. I also do not know of any comparable formal rules for pattern derivation that have been proposed by others, even though the best practices discussed in the paper are frequently applied and well known in the ontology community. Overall, I think that the intentions and ideas of the authors are definitely worth considering.

However, the paper leaves very much to be desired. First and foremost regarding clarity and completeness of the description, as well as regarding the arguments for the pattern. The text is in a condition which (honestly) makes it almost unreadable, even for experts on the topic. And this is not due to the complexity of the issues or the formalization, it is rather simply a consequence of a very bad style of writing. Here are some concrete details:
- The authors introduce their abstract ideas almost entirely without making examples. Even though the tables show a few of them, the text lacks illustrations and examples in almost all cases where new ideas are introduced, which makes it notoriously difficult for a reader to follow the suggestions or arguments made. For example: What exactly are types with singular nominal expressions? I could not find an example.
- Furthermore, the authors seem to struggle with their own (predominantly unexplained) terminology. Are they talking about types of relations or about concrete relations? Are they talking about concepts, processes and roles in the sense of classes or individuals? This remains unclear to the reader. For example, sometimes, they talk about processes in the sense of individuals (e.g. the particular "landing of Joe at Omaha beach on D-day") and sometimes, they explicitly talk about processes as types (classes). What exactly do they mean?
- The text contains many potentially interesting claims/conclusions regarding ODPs. However, they are not in any way systematically introduced, ordered, discussed, explained, and argued for. For example, the authors say that "DnS includes relation types which can be derived from process types". But they never make examples or illustrate such claims. Claims such as "People creating such types tend not to give them definitions with respect to a process" are unacceptable without references or further arguments. Another example for such an unsupported claim is "Most statements implicitly or explicitly refer to a process. ...". The authors also claim that the pattern was applied to the MSO database without further discussion.
- After reading the paper, I was still unsure what exactly belongs to the proposed ODP and what doesn't. Contents of Table 2? Table 3? Table 4? In Table 5, it seems that there is only one formal pattern proposed by the authors (in thick), whereas the other ones are informal statements distributed in the text.
- The goals, structure and methodology of the paper remain obscure. In the introduction, the authors claim that the proposed pattern should lead knowledge providers "to create more precise, normalized, well related and easy to understand KRs". I cannot see how this paper could convince a reader that this is actually the case. In order to do so, the authors would need to completely rewrite the paper: starting with a clear illustration of the specific challenge addressed (maybe based on examples from ODPC), and building up their arguments, always illustrated with convincing examples, which then eventually lead to their pattern proposal. The current version of the paper is far from this, which is why I can only reject it.

There are several very interesting points made in this paper, but overall it is very challenging to follow.

The paper begins by defining an ODP as a "modeling solution to solve a recurrent ontology design problem" and clearly explaining the criteria for a good ODP. Section 2 then describes the goal of the paper as introducing an advocated best practice for representing n-ary relations as binary relations and clearly explains why this is a useful thing to do. The authors do not claim that this transformation from n-ary to binary relations is original, but instead convincingly argue that it makes sense to have an ODP that guides this transformation. The paper also provides naming pattern advice in addition to the more traditional ODPs presented, which is very useful and not commonly done.

There are several high-level things about this paper that are concerning, however:

The paper conflates the concepts ontology design pattern and best practice. The authors argue that one source lists best practices as part of an ODP library, but not separating out these ideas in this paper makes the paper confusing. Whenever the authors make a claim related to ODPs, it is unclear precisely what they are including in that claim: just ODPs, just BPs, or both. In particular, Table 5 and the discussion related to it in the text are solely about BPs.

Section 6 contains several ideas that are confusing. For instance, the authors hypothesize that structuring an ODP library as a finely organized hierarchy or graph would make it easier to locate relevant ODPs and less likely for the library to contain duplicate ODPs. The idea would be to formally represent each ODP as a process, using the same base ontology. It is very unclear that it is possible to represent all types of ODPs, particularly all content ODPs, as a process. The authors also distinguish between subtype hierarchies and taxonomies in this section, but it is unclear what the difference between these two things is. In general, this section seeks to show the relationships between the ODPs presented in this paper to other existing ODPs, but it actually describes the characteristics of the collection of best practices advocated by the paper.

The overall organization of the paper makes it hard to digest. According to the conclusion, the paper presents various kinds of ODPs, including architectural, logical, content, and naming ODPs, all of which follow from similar derivation mechanisms. It would be best to introduce the general idea of these derivation mechanisms in the beginning of the paper, and then break each ODP out into its own section that explained the particular derivation, the ODP, the axioms underlying the ODP (which are currently entirely missing from the paper), and example uses.

Some more minor issues include:

Things that would normally be figures are referred to as tables (e.g. Tables 3, 4, and 5).

The second row of Table 1 seems to be missing a statement r_extended_specialization(?C ?C_at_time_T) r_time(?C_at_time_T ?time_T)

In Tablel 4, the label in the upper right reads "r__relation_to_another_spatial_entity" but should probably instead be "r__relation_to_another_temporal_entity". On the left side of this figure, the comment for r__predecessor_state lists r__cause twice.

The statement "It should be noted that the practical absence of "necessity to use non-binary relations" is compatible with formal proofs that "besides unary and binary relations, there must exist at least one ternary relation in order to generate all possible relations." seems to contradict itself.

It is unclear why the term "gradual pattern" was chosen to describe the "the more X, the more Y" relationship.

There are some grammatical errors (that become more frequent towards the end of the paper). For example:

There is no article prior to ABP throughout the paper, e.g. "ABP starts by advocating..." should be "The ADP starts by advocating..." and "Since ABP is language independent..." should be "Since the (or this) ABP is language independent...".

"... thereby also give more rationale" should be "... thereby also gives more rationale"

"only the third row is also about the focus of Section 3: deriving a relation from a concept" needs to be reworded

The caption for Table 1 "Examples of how and why defining a given relation type with respect to other types" needs to be reworded

"This is useful as a intermediary step..." should be "This is useful as an intermediary step..."

"First, it avoids that some knowledge providers develop..." should be "First, it avoids the problem that some knowledge providers develop distinctions only in the..."

"When genuine definitions or rules are manually given for each derived relation, as illustrated in the third row of Table 1, the advantages of the approach (over directly using relations without defining them) only come from the existence of this definition." needs to be explained more clearly.

The paper claims that concepts can be quantified while relations cannot (e.g. 3 landings can only be described via the concept "Landing" and not the relation "r_landing"). It is not clear why this is true.

In the caption to Table 2 "... signature associated to this concept type" should be "... signature associated with this concept type"

"... any type derived from noun-related part of the..." should be "... any type derived from the noun-related part of the..."

"... which are directly associated to certain top-level concept types" should be "... which are directly associated with certain top-level concept types"

"These rules permit to give a formalization of the framework" should be "These rules enable a formalization of the framework"

"... if a concept type is associated to two signatures..." should be "... if a concept type is associated with two signatures..."

"... amounts to loosing precisions..." should be "... amounts to loss of precision ..."

Please note that this list of grammatical errors is not complete.

The paper proposes a new ontology design pattern for representing knowledge in a more precise way. The pattern is based on binary relations.

The title of the paper, in principle, shows a very interesting work about binary relations on processes and roles. However, the paper is too much vague: the main objective of both the paper and the pattern is not clear enough. In addition, the existing gap in the field in not well identified.

When a paper is about a pattern, what is expected is to find the pattern structure, the model (representing the solution the pattern gives to a particular problem), the requirements for using that pattern, the consequences on using the pattern, and some use cases or examples in which the pattern can be applied. However, this paper does not include any of this knowledge.

Other comments:

- Authors should explain why they are using strange acronyms for structures like 'adjective + BP'
- Authors should also clarify the difference they consider between best practice and pattern.

- Authors mention that most of the existing best practices are domain and language independent. This sentences should be explain in detail. In addition, there is a type of pattern called content ones that are domain dependent.

- In Section 2, it is not clear enough the need of functions.

- Some English mistakes should be corrected (e.g., "this pattern is: "using..."). In addition, authors should review the language used.

- "previous sections" should be replaced by the particular sections authors would like to mention.