Semantic representation of Design for Manufacturing and Assembly offsite housing

This manuscript was submitted as 'full paper' and should be reviewed along the usual dimensions for research contributions which include
(1) originality - no clear originality demonstrated, no clear comparison to existing state-of-the-art approach tackling similar issues
Initial review: The contribution depicted in the article at hand concerns the definition, from scratch, of a new ontology for cost modelling (OHO-Cost) and implementing it in a Web-application. There is an attempt to justify why a new ontology for cost modelling is needed, but the arguments provided are not strong nor clear enough. Authors acknowledge the existence of "Linked Data" (approach, not principles - page 2, lines 17 & 27) but do not provide any links to existing similar (if not equivalent) concepts and properties from other ontologies
Revision: not addressed, no links defined, still apply to the revision provided

Initial review: Authors justify the need for a new cost ontology by checking DfMA requirements (not cost estimation requirements) against various existing ontologies with very different scopes (building topology, eCommerce, products, etc.).
Revision: Inserted contents in the article mentioning that "this study first reviewed the current use of BIM and identified that there is a lack of manufacturing information in BIM models." - no such review was found in the revision
"we found that no ready-to-use and similar solutions can be adopted to integrate building design, product and production knowledge" but in the conclusion, authors claim they have "extended ifcOWL" (the revision holds no contents justifying this claim) - thus, on the one hand, the OHO-Cost ontology is defined from scratch because no "ready-to-use" solution exists and, on the other hand, this ontology is considered an extension of an existing one. Typically existing cost ontologies could've also been extended, and adapted with regard to ifcOWL. Basically, a new ontology is developped because "none of [the existing ontologies] can be applied directly without further ontology development"
In the response to reviewer's letter, the authors mention "The innovation of this study is process-based cost estimation. The previous studies on cost modeling are element-based, which has no relation to the production activities. This is the reason why a new ontology, like OHO is needed." The article holds no proof of such "innovation", left alone how it specifically addresses "production activities" and how other existing approaches fail in doing so. It is unclear what authors mean with "element-based" when referring to previous studies. No clear references are provided in relation to this claim, neither in the letter nor in the article.

Initial review: Unfortunately, the article does not describe what are those "specific aspects" of DfMA that could not be handled with Linked Data (which allows combining elements from existing ontologies for annotating existing DfMA data).
Revision: This point is still not addressed, and given the reason provided for developing a new ontology without linking it to existing ones, the contribution presented here only raises semantic heterogeneity along with the number of existing ontologies, thus going against Linked Data principles.
Mentions such as "For instance, a oho:House is-a bot:Building or when the concepts are used together, they can be linked or distinguished using computer-readable relationships, such as sameAs and differentFrom" highlight a misunderstanding (for the least) from the authors regarding Linked Data principles and ontology alignments.

Unaddressed review elements:
- Table 2 should "show" that none of the existing ontologies can be applied directly without "further ontology development" for capturing "specific aspects of DfMA".
- It is unclear why the latter has been chosen and how the phases depicted in Fig. 1 have been addressed
- The relation between phases and scenarios listed in Fig. 1 and competency questions defined is never discussed
- The NeON methodology is never mentioned during the presentation of the OHO ontology but used for section 6 Evaluation of OHO
- Also from Table 3, this article only focuses on cost estimation - thus the contributions claimed should be compared with existing approaches using ontologies for cost estimation (e.g. the cost estimation ontology from Abanda et al - page 4, lines 47-49). Such work is missing from the paper at hand. Authors must define what "key requirements" of DfMA cost estimation cannot be implemented or addressed using or combining existing ontologies. The KBE tool (section 6.3) should clearly demonstrate the implementation of functionalities that are missing from other approaches.
Authors must also demonstrate what "key requirements" identified for DfMA are enabled with the KBE tool.

Unaddressed comments:
- "Data exchange" can be performed without ontologies. What specific issue is tackled that cannot be achieved with existing tools and solutions for "data exchange" ?
- What exact "vision" can be enabled or supported by ontologies and cannot be with other processes or tools ?
The reply provided by the authors fails in answering these questions "Ontology provides efficient data exchange among various domain knowledge representations, enabling interoperability among different applications. The ontology-based approach can provide a machine-understandable structure in which concepts and knowledge are represented. It is not just for data exchange but more importantly for knowledge representation and application."

(2) significance of the results - scope is unclear whether is concerns cost estimation or production, relation to existing ontologies is not demonstrated, no comparison with any existing approach
Unaddressed review elements:
- Initial review: "While the scope of the article appears to be "cost estimation" (from Table 3), most of its sections deal with oho-prod. OHO Costing module is only presented in section 5.3 (the related ontology is not available online - 404 errors see below) and no clear use case is presented highlighting how elements from OHO can be used for cost estimation". Revision: In their reply, authors simply mention the "innovation" tackles "production" while the article's conclusion claims a contribution regarding "cost estimation". the article holds no demonstration of some innovation regarding production.
- It must be part of any research approach to compare the proposal with what's existing, using some indicators. Developing an ontology from scratch and not comparing it with any of the existing approaches cannot be evaluated - thus the conclusions of the article are not supported by the contents provided
- properties are never presented as object or data properties (just plain properties)

Partially addressed comments:
- Initial review "the modelling choices are unclear and unjustified (e.g. the oho:composedOf property description on lines 35-38 and the representation provided in Figure 2 - which misses a legend)". Revision: partially adressed, but no reply regarding specific modelling choices mentionned in the comments e.g. usage of owl:unionOf and anonymous classes. A legend was added to Figure 2 but incomplete - several links are used in the representation (some property and class names in bold, some not), several colours are used in the figure for classes (light blue, dark blue) and also several geometrical shapes (e.g. oho:House and oho:Product). The figure remains unclear as it links a concept (oho:House) to two ontologies (OHO-Pro and OHO-Cost)). No discussion provided regarding modelling choices.
- Initial review "All the advantages cited for the OHO ontology are common to all existing ontologies - thus every ontology facilitates extensibility, can be adapted and extended and can be used for optimization and automation. For example, the ifcOWL-DfMA ontology could be extended in order to address cost estimation". Revision: one sentence is added in the conclusion claiming that "OHO expanded the ifcOWL ontology and used a real-life use case production lines to test and demonstrate the benefits of the semantic digital twin in obtaining data of the manufacturing for Assessment". The article holds no contents justifying such "extension", and as mentionned in the previous review the "advantages" claimed by the authors are common to all approaches based on ontologies. Authors do not clearly demonstrate any specific benefits broughts by their approach in comparison to other approaches based on ontologies for tackling similar issues. The article contains a description of a development approach, not a research one.

Unaddressed comments - authors simply mention in their reply that they have uploaded "a new version of the ontology online" and that the reviewer can "check'"it (reply provided for the 3 cquestions below)
- Why 3 anonymous classes all for defining the same owl:unionOf between oho-cost:House and oho-cost:Panel ?
- Why is there also 2 same anonymous classes defined for owl:unionOf between oho-cost:Location and oho-cost:Coordinates ?
- Why is a (rdf:Property) defined reflexive for all subclasses ?
- What exact "vision" can be enabled or supported by ontologies and cannot be with other processes or tools ?

Partially addressed comments:
- Initial review: "What are the "recommendations" provided by the W3C Linked Building Data CG and how does the OHO ontology respect those ? The 4th principle of Linked Data states that outgoing links should be defined towards terms defined in other ontologies and there are no such links provided in OHO."
Revision: Authors reply mentioning "The recommendation followed by W3C Linked Building Data CG in their publications was about modularity i.e. the work to modularise ifcOWL. About linked data publication we aimed to follow the principles of Linked Data. We have revised the ontology by adding links to other terms form other ontologies." No references are provided. The article does not mention nor discuss any existing links to terms in other ontologies.

(3) quality of writing - English correct (some typo mistakes remain), the main concern is that figures do not have a common legend while representing the "same" elements (e.g. classes, properties) for example Figure 7 and Figure 2 and Figure 3 all have 3 different types of legends.

(4) whether the provided data artifacts are complete - links below still point to 404 errors, while authors reply that "the links have been fixed".
OHO-cost module is not available - 404 errors for https://edlirak.github.io/oho/ohoModules.owl , https://w3id.org/oho-cost#

The authors appear to have adequately addressed most of the comments indicated in the review. However, there are still some issues that have yet to be resolved. In particular, I see two major problems remaining:

The first one refers to one already indicated in the previous review about the availability / accessibility to some of the outcomes of this research while others, such as the location of the OHO ontology, are not clearly indicated. For example, the following link is not provided:
https://edlirak.github.io/oho/index-en.html , https://w3id.org/oho
what about the dedicated set of built SWRL rules, and sample RDF datasets, the KBE tool,…? If I am not mistaken, this question has not been addressed. I have not been able to find any available links or indications about that. As I mentioned in the previous review, its access would facilitate a better understanding about its development, organization, and reusability. The latter is a very important issue because the objective of proposing an ontology in a context like the one presented in this article should be to make it possible for other users to access it to see how to use it for their application case.

The second issue has to do with the lack of specificity in some explanations of the paper that, despite being revised, modified, or introduced after the revision, still give the impression of being a bit vague and inaccurate. The way of expressing some ideas and providing arguments in specific parts of the article suggests that the authors do not have a deep knowledge of the topics, at least in those parts. For example, Linked Data is one thing, semantic web technologies are another, and ontologies and OWL ontologies are another. In some parts of the article these terms are inappropriately related or confusingly named.

questions to review by sections...

1. Introduction

Page 2, Lines 29-40 (new paragraph): its content should be more concise and contextualized. For example, in “…there is a lack of manufacturing information in BIM models.”, it should be indicated in which processes this information is necessary. In those related to DfMA? And for what? More connection between the different elements is needed. Following with the paragraph, it is said that "To integrate manufacturing information into BIM, a data exchange is required.", this is simply not true. More contextualization is needed about the situation that the authors have in their minds. What does integration have to do with data exchange in a general context? How are these two questions linked? Then “Semantic web technologies and Linked data has proved to facilitate data exchange” is a very general statement. Again, conditions and context are necessary to justify how such statement is applicable in your scenario.

Page 2, Lines 48-51: please, review / rewrite the beginning of the next sentence “In the end, the OHO was discussed to accommodate…” In the end? Discussed?

2. Limitations and potentials of data models for DfMA

Page 2, Lines 7-12: it would be more correct to express it the other way around. That is, for example, instead of “it is common to have process-related data, typically used for the scheduling (i.e. 4D BIM)”, “for the scheduling (i.e. 4D BIM), it is common to have process-related data”.

Page 2, Lines 28-32: false statement. IFC is widely used in practise to support the representation of buildings, but in the STEP format and not in the semantic web format. The use of the RDF format to represent IFC models in RDF (according to ifcOWL) in BIM software is currently testimonial.

Page 2, Lines 37-40: confusing sentence “Thus, the use of the IFC schema alone will miss the chance to implement DfMA that requires knowledge representation of the production and assembly attributes as well as cost [2].”, what the authors are trying to say is not clear enough.

3. Related works: Ontologies and Data Models

Page 3, Lines 9-10: “...four different domains of ontologies have been reviewed…” or “existing ontologies in four different domains have been reviewed”? ‘domains of ontologies’ is not correct. Ontologies can cover domains but not vice versa.

Page 3, Lines 23-26: again, lack of accuracy in what is expressed. What do you mean by “IFC itself”? The use of semantic web technologies “by itself” do not solve anything. The representation of an IFC model in RDF does. I suggest the authors review again what exactly reference 33 says about it (Rasmussen et al., 2019). --> “IFC does not fulfil requirements REQ3 and REQ4 in that it is not web-compliant, and fails at enabling the integration of building data with other types of data on the Web.”, where “REQ3 = Use of a set of interoperable, flexible, and open, standards covering different domains” and “REQ4 = Support of distributed data integration, linking and tracking at data level.”

Page 3, Lines 42-45: the W3C Linked Building Data (LBD) Community Group is not focused on how to modularize the IFC ontology to improve its extensibility, but on providing an alternative through a modular ontology approach. Again, I suggest the authors review again what exactly reference 33 says about it (Rasmussen et al., 2019) --> “…to provide a simple option to reach semantic interoperability and enable data integration on the Web in the AECOO industry.”.

Page 4, Lines 4-8: Regarding PRODUCT ontology and “The PRODUCT ontology consisted of the IFC classes underneath the IfcElement node, while the PROPS”, this does not seem consistent with what it says here: https://github.com/w3c-lbd-cg/product. By the way, it would be nice (necessary) to include some references here about PRODUCT and PROPS.

Page 4, Lines 4-8: again, lack of accuracy in “The Building Product Ontology (BPO) is a multi-layered product ontology, which was designed to overcome these shortcomings” what shortcomings?

Page 4, Lines 23-28: review the relation between semantic web technologies and ontologies in the argumentation. More than semantic web technologies, here the problem seems more of a lack of ontologies as standards. Even non-OWL ontologies.

Page 5, Line 3: “ontolgoies” --> “ontologies”. And, “ontologies” or “OWL ontologies”?

Page 5, Line 23: A space is needed in “…process-based.The…”

4. Method

General comment on this section: the way it is fitted in the article does not seem entirely logical (I remember having indicated it in the first review, although the organization was different). It seems more logical that the content of this section should be a subsection of the next one. There is no point in talking about a method for developing an ontology, and then introducing the ontology in the next section. I suggest the authors rename section 5 as “5. OHO ontology” and then introduce the OHO ontology (via “5.1 Overview” section) and then explain the steps for its development (section “5.2 Development” o “Method”), for example, following the logical order of appearance that a reader would expect to find.

Regarding Table 2, perhaps the authors could improve its quality, for example, by providing some description about the use cases or including some reference to where to find this description in the article. It could be interesting to relate the use cases to the users. I understand that not everyone participates in all use cases. This is not important, just a suggestion.

5. OHO Overview

About Fig. 2., I am not totally clear about the response provided by the authors regarding my comment. There is no problem in modularize OHO into OHO-Core, OHO-Pro, and OHO-Cost. The problem is with purple and green boxes representing domains. If they are domains, then there cannot be arrows from classes going there because is confusing. Arrows should only exist between classes (or a class and a literal), which is what happens at the top of the figure. I understand that the authors do not want to include all the classes of OHO Production (OHO-Pro) and OHO Costing (OHO-Cost) because there are many and the scheme would be intelligible, but the current solution brings confusion. Also, the legend at the bottom does not help to understand it. By the way, I would use the same full name for the domains in any part of the article (figures included) without abbreviations to avoid confusion. Also, in naming the sections: “5.1. OHO Core”, “5.2. OHO Production”, “5.3. OHO Costing” (without “module”).

Regarding section “5.3. OHO Costing module”, this section is very short and without example compared to the previous two ones. Is there any reason for it?

Pag 13, Lines 50-51 and 1-4 (next column): I think this first sentence is grammatically incorrect.

6. Evaluation of OHO

Page 14, lines 44-45: About “It was tested using Protégé to demonstrate that the schema is consistent”, is the Protégé the key piece to validate the consistency of the scheme or is the Pellet reasoner? this seems at least incomplete. Schema consistency checking can also be performed with online tools/services such as OntOlogy Pitfall Scanner (OOPS) (Poveda-Villalón, 2016) http://oops.linkeddata.es/, for example.

7. Demonstration of the OHO ontology

Fig. 7 still has some issues to improve. The graphics representation should be better. The lines should not go over the diamonds of any instance. The indication of “inferred” has disappeared from the legend. Property names should not be traversed by their relationship lines.

Regarding section 7.4, I propose to the authors to rename the titles by the following:
7.4. KBE tool Development --> KBE tool
7.4.1. Input of the KBE tool --> Input data
7.4.2. Output of the KBE tool --> Output
7.4.3. KBE Architecture --> Architecture
7.4.4. Validation of the KBE tool --> Validation

By the way, is it an online-accessible tool? has it been developed through an online repository?

Page 19, Lines 35-38: the OHO ontology “was used to implement a” Knowledge-Based Engineering (KBE) tool, or “in the implementation”. What is normally “used to implement” a software is an IDE.

Regarding Fig. 11 (Fig. 9 in the first version of the manuscript), I indicated that the architecture of the KBE tool was not very clearly represented in the figure. Despite the clarifications provided in the text, a more uniform symbology indicating the relations between the different elements should be needed in the figure. Now is too generic.

5. Conclusion and discussions

Page 20, lines 34-38: I disagree with what is stated in the newly added part, and in particular with this saying that “OHO expanded the ifcOWL ontology”. What does ifcOWL have to do with OHO? What expanded? why not other AEC ontologies? What about BOT?

Authors have addressed most of my previous comments. I think that the article now may look more precise and may be interesting for the community.

As a last suggestion, I would recommend authors to include in the article some of the comments they added in the 'Response to reviewers' document as an answer to my questions. There could be readers that may come up with the same questions, so clarifying issues beforehand can be beneficial.

Other than that, I would simply like to thank and congratulate authors for their article.