Semantic representation of Design for Manufacturing and Assembly offsite housing

This article presents an ontology for Design for Manufacturing and Assembly (DfMA) approaches: the OHO (Offsite Housing Ontology). After analyzing existing ontologies, authors proceed to explain the methodology used for developing the ontology, and the details of the ontology itself. Afterwards, the ontology is evaluated and applied in a use case. Since the article has been submitted as 'full paper' and will thus be reviewed in along the usual dimensions for research contributions which include originality, significance of the results, and quality of writing.

In general, the article addresses an original and relevant topic, but it fails to clearly state which are the main contributions. On the one hand, it is not clear which are the existing gaps in the domain at hand, and therefore, it is not clear which are the major contributions of the proposed article. Authors should try to better identify which are the requirements of the domain, to which extent existing ontologies cover such requirements, and specify how uncovered requirements are addressed. Likewise, it is important to clearly state the criteria followed to analyze some specific ontologies and no other ones. For that purpose, survey articles published in previous volumes of Semantic Web Journal could be of inspiration. On the other hand, the ontology itself lacks many essential elements (e.g., license, metadata, alignment files,...) that may facilitate its reuse by the Semantic Web community. Ontology developers should improve the ontology, its modules and make sure that all the elements are FAIR-compliant. it is equally important to make a thorough review of existing tools and services to evaluate the ontology. Finally, the article is not easy to follow, as it has disjointed and repetitive ideas at times. Authors should try to rewrite many parts of the article so that it can be easily followed and understood by the reader. All in all, the reviewer is in favor of a major revision of the article at hand.

Some more in-depth considerations and comments:

(1) Introduction
- P1, L46: Could you provide some more details on what DfMA consists in?
- P2, L13: "the study". Which study do authors refer to?
- P2, L15: "efficient data exchange relies on the application of semantic web technologies and linked data". Aren't there any other technologies that enable efficient data exchange? Maybe authors could better explain which are the benefits of SWT and LD in data exchanging scenarios.
- P2, L20: "(...) were found insufficient for implementing DfMA". Who found this? Is there any article that supports this claim? Or is it what it was found in this article? If so, it would be better explained.
- P2, L24: "knowledge-based tool". Is it referring to the "Knowledge-Based Engineering tool" mentioned in the abstract?

(2) Limitations and potentials of data models for DfMA
- P2, L37: BIM acronym is already defined.
- P2, L9: "BIM applies an ontological representation for data exchange". Is this true? Aren't there non-ontological BIM approaches? Like file-based approaches?
- P2, L10: "IFC supports the use of semantic web technologies". What do authors mean? And what is IFC? At this point, the term is not explained.

(3) Related works: Ontologies and Data Models
- P2, L37: Why are four types of ontologies reviewed? And why these four and no other fours? Which is the criteria?
- P3, Table1: What do values of the category column mean? These aren't the same four types of ontologies mentioned before.
- P3, L21: OWL acronym should be defined in its first appearance
- P3, L25: IFC is not the same as ifcOWL
- P3, L28: "The complexity of this ontology makes reasoning and management very hard and inefficient". Not only the complexity, but also, its counterintuitiveness with Semantic Web Principles [PAW17]
- P3, L36: initiate is used twice in the same phrase. It sounds repetitive
- P3, L40: Why is '[' used instead of '(' ?
- P3, L20: Are Zone, Element and Interface really the three main classes of BOT? What about Building, Storey or Space?
- P3, L31: Why isn't BRICK reviewed?
- Not every ontology has been reviewed the same way. A recent survey on ontologies for buildings could be helpful [ESN20]
- P4, L8: GoodRelations and Schema.org. I wouldn't say that they are product ontologies. Their goal is much more generic than that.
- P4, L15: Why a non-modular ontology cannot have linkages to other ontologies?
- P4, L24: "(...) do not align with other common manufacturing vocabularies". Maybe it should be clarified that this is not a shortcoming of the ontologies. On the contrary, it's totally understandable, as they are building-domain ontologies.
- P4, L33: "evaluate". Should be replaced by 'support', 'facilitate' or a similar word?
- P4, L41: "is a standardized manufacturing ontology". Who is the standardization body behind this ontology? How is it that it is a standard but it is not even available on the Internet?
- P5, L14: In general, it is not clear why these building, product, production and cost-related ontologies were selected and no other ones.
- P5, L18: "It shows that while existing ontologies partially capture specific aspects of DfMA". It is not clear which are the DfMA aspects that should be covered and their relevance (why should they be covered?).
- P5, L49: "Which can be connected to both ontologies through general associations rather than strict formal connections". What does this mean?

(4) Method
- P5, L17: "This study used a house production case that has adopted DfMA for its automated wall panel design as the basis for the development of an offsite house design ontology". It sounds like with this approach the ontology may be biased towards this specific use case, thus losing its genericity for the whole Offsite Housing domain. How can authors make sure that the ontology is valid for the other use cases within the same domain (if that's the final goal)?
- P6, L23: "An analysis of non-ontological resources such as BIM model, manufacturing process reports. etc was done in the Reuse phase". Which are the results of this analysis? Weren't ontological resources analyzed too within this same Reuse phase?
- P6, L30: "The review identified a lot of shortcomings". Which are those shortcomings? This kind of information could be very relevant for the reader.
- P6, L35: "Then, a set of competency questions were drafted". Shouldn't CQs be defined in the very beginning? Otherwise, how can you evaluate the coverage of existing ontologies with regards to your domain of interest?
- P6, L22: "The OHO ontology were then presented". How was the ontology presented before its formalization?
- P6, L34: Are these all the CQs? Which of them are covered by reviewed ontologies? CQs should be presented earlier.

(5) OHO Overview
- P8, L8: "allow reasoning and automatic calculation". Of what?
- P8, L11: "The proposed ontological model is language independent". What does it mean? Isn't it in OWL?
- P8, L15: "a limited number of very high level concepts is needed". Why is that? And concepts from which domain: construction, offsite manufacturing, processes...?
- P8, L16: Why wasn't BOT reused then? The relationship between BOT and OHO should be provided by the developers. Otherwise, different users may have different conceptualizations and may relate ontologies in a different manner that developers designed.
- P8, L31: "this core module also includes production line aspects". Weren't they part of OHO-Pro?
- P8, L34: Why isn't this order of concepts maintained in the next subsections? Shouldn't OHO-House be included in this list?
- P8, L49: The whole paragraph is repeated.
- P9, L43: Why are two different concepts oho:Product and oho:product?
- P9, L46: This sentence between brackets should be in the next subsubsection as it provides information related to components.
- P9, L49: oho, Pod, oho:Panel and oho:PodFrame. What are these? Why are these 3 defined and no others? Aren't other products that can be produced using a DfMA approach?
- P9, L31: Why are terms from Table4 defined and no other ones? Which is the criteria followed?
- P9, L34: "using transitivity between OHO classes". Isn't transitivity a property? What do you mean by this?
- P9, L38: This means that individuals in the range or domain of this property, will be an individual of both classes at the same time (oho:House and oho:Product or oho:Component and oho:Product). Is that what you want?
- P9, L48: "The oho:Interface class allows to..." the sentence is repetitive.
- P10, L26: The same happens here. If an individual is in the range of the property will belong to two classes at the same time. Is that what you want?
- P10, L33: "detailed subclasses and object properties were not introduced". It has been done in the oho:Product class though. Why is it different for this class? If there is any reason, it should be clearly stated.
- P10, L30: From here until the end of the subsubsection, it sound more like an explanation of a design choice rather than the oho:Production. Therefore, this fragment should be moved into another subsection.
- P10, L47: "imports the OHO core". That's not true in the ontology version available online on 2022/02/07
- From this point onwards, there are too many classes and properties that are not defined in the ontology. oho-prod:Station, oho-prod:isStartingStation, oho-prod:IsFinalStation, oho-prod:Labor, oho-prod:hasMethod, oho:CladdingAssemblyLine,...

(6) Evaluation of OHO
- P14, L27: This domain coverage evaluation is insufficient. Maybe some metrics could be used to support his task. Which percentage of CQs are covered, for example?
- P14, L40: "assesses the quality of the ontology based on a set of metrics and a list of attributes". Are these retrieved from any known methodology? Or are metrics selected by authors? Which are the criteria used to select these metrics and no others?
- P14, L49: What does each of the analyzed attributes mean? [ESN21]
- P15, L25: "the processes were supported by highly accurate non-ontological resources". Which processes do you mean? What do you mean by assist?
- P15, L29: "each module can be used independently". How can this be proven? Did you use any tool to measure this? Which are the cohesion, encapsulation or coupling degrees of the ontology? [KHA16]
- P15, l35: "terms contain non-ambiguous names". This sounds rather subjective. How can you measure this? Most terms do not contain enough metadata, so it is difficult to understand the authors intent in their definition. Look at https://w3id.org/widoco/bestPractices for metadata best practices
- P15, L44: "the queries run in milliseconds in each of these environments". What if there are millions of triples? Can you ensure a high efficiency? The way it is written, this attribute sounds more like an RDF Store metric rather than an ontology design.
- P15, L30: Some general ontology remarks. The ontology has some arguable design choices (e.g. why was a oho:Thing class defined? What it's purpose?). Which is the ontology's license? Why does the ontology contain individuals like 'Window-1', 'Wall-1',... If anyone wants to reuse OHO, they would also reuse these terms which sound more like specific use-case individuals.
- P15, L33: KBE. What does it mean?
- P16, L28: At this point it is unclear the role of ontologies in the KBE tool. Which are the benefits of having used (in case it has been used) the OHO ontology?
- P16, L29: In general, this whole section is not very clear. Difficult to understand. Maybe following a homogeneous and ordered way to explain things could help.
- P16, L33: "The data used are based on a platform..." This part (until L45) doesn't provide architecture information. It sounds more like the example Use Case's.
- P16, L51: "... transforms th relevant information into the RDF format". How is it done? Which are the ontologies used? How are they used? How can you convert a file into RDF and then use OHO concepts (as stated in the next sentence)?
- P16, L19: "the outputs generated were close to their estimates". How close? Try to be more specific.
- P16, L20: "the estimated costs generated from KBE tool were also compared". And which are the results obtained?

(7) Application of the OHO ontology
- P16, L36: "in order to extract the captured and inferred data". At this point, it is not clear which kind of data can be inferred and how.
- P16, L50: Why were SQWRL used rather than SPARQL? Where were these queries tested? In the scenario presented later in page 20? And what are the results obtained by each query? How were these results used in the use case?
- P19, L37: Listings 10 to 14?
- P19, L38: "A number of relevant SPARQL queries to extract knowledge from a pod product". With which purpose? How does this pod production information help in the offsite manufacturing process?
- P20, L38: "The rule on Listing 12...". This kind of explanation would help to complement the SPARQL queries and help readers to understand them.
- P21, L32: "The data input to the Pellet reasoner and those input to OHO OWL ontology in a Protégé environment give exactly the same result". Not sure what you mean by this.
- P21, L41: What does Listing 14 exactly validate?

(8) Conclusions and discussions
- P22, L44: This is the first time the reader finds out that OHO emerged from the ifcOWL-DfMA ontology.
- P22, L32: These alignments should be developed by the ontology developers and provide them to foster the ontology's reusability. How different ontologies relate can be interesting and should be explained in previous sections.

REFERENCES:
[ESN20] Esnaola-Gonzalez, I., Bermúdez, J., Fernandez, I., & Arnaiz, A. (2020). Ontologies for observations and actuations in buildings: A survey. Semantic Web, 11(4), 593-621.
[ESN21] Esnaola-Gonzalez, I., Bermúdez, J., Fernandez, I., & Arnaiz, A. EEPSA as a core ontology for energy efficiency and thermal comfort in buildings. Appl. Ontol. 16 (2), 193–228 (2021).
[KHA16] Khan, Z. C., & Keet, C. M. (2016, November). Dependencies between modularity metrics towards improved modules. In European Knowledge Acquisition Workshop (pp. 400-415). Springer, Cham.
[PAU17] Pauwels, P., & Roxin, A. (2017). SimpleBIM: From full ifcOWL graphs to simplified building graphs. In Ework and ebusiness in architecture, engineering and construction (pp. 11-18). CRC Press.

Dear authors,

This article addresses an interesting topic that could be of interest for the semantic web community. The article is well written and is a worthwhile paper that deserves publication. The topic is clear and concise. However, the article includes some inaccuracies and misleading claims that should be revised. I am adding a few comments and possible recommendations to improve the article in each of the sections. None of them stands in the way of publication. Yet, it would be great if the authors can still address these comments in their paper.

General comments: Apparently, there is no link to a data repository, website, or OWL file with the OHO ontology presented in this article. The dedicated set of built SWRL rules is also not provided, and / or any sample RDF data set is available. Its access would facilitate a better understanding of all the details provided in the section about its development and organization and would support everything that is explained in the section on its application. Also keep in mind that if the objective is that third parties can reuse the ontology, it should be accessible.

Abstract: is appropriate and reflects enough what readers would expect to find in the article.

1. Introduction
Lines 16-20: the authors state that “efficient data exchange relies on the application of semantic web technologies and Linked Data”. There is no direct evidence for this. It can be said that the application of SemWeb technologies and LD can help in providing this, as well as that they can also be useful in providing reasoning within the context of knowledge representation, …as the authors comment in the following lines of the text (applications where the semantic web can take advantage).
Pag 1. Lines 26-30: please review the las part of the sentence “As OHO is extensible, the semantic web technologies and Linked Data (LD) approach used can be used to accommodate a wide range of offsite products, and extended to other functions such as the optimisation of modular production.”

2. Limitations and potentials of data models for DfMA
Pag 2. Line 9: the following sentence “BIM applies an ontological representation for data exchange.” is inaccurate. It “applies”?
Pag 2. Lines 10-11: the following part of the sentence “While IFC supports the use of semantic web technologies” is inaccurate. “Supports”? There is a version of the IFC schema represented in OWL created to be used in semantic web applications. So here, perhaps it would be more appropriate to say that IFC supports representations in semantic web formats (e.g., OWL).
Pag 2. Lines 18-23: review the punctuation of this sentence “Thus the use of the IFC schema alone will miss the chance to optimise modular design through DfMA implementation that requires simultaneous evaluation of the production and assembly attributes as well as cost, to support design decisions [2].”

3. Related works: Ontologies and Data Models
Pag 2. Line 38: in the sentence “Four different types of related ontologies have been reviewed”, rather than “types” it would be more appropriate to say “domains”, or maybe the authors could say “ontologies related to four different domains have been reviewed”.
Pag 3. Line 41: about the sentence “Generally, it is anticipated that BIM data will be communicated efficiently inter-disciplinarily using web-based technologies”, there is nothing to indicate that it will be so, much less in a general way. If the authors are totally sure of this statement, they should offer at least some references that support this theory.
Pag 4. Line 8: I am not sure Schema.org is a good example of a common product ontology.

4. Method
In an article focused on the development of an ontology, a reader would expect to read in this section the steps/phases that have been followed to carry out its development. So, I suggest authors remove the introductory part of this section which seems redundant and start directly with the first subsection.

4.2. OHO Competency Questions
About the competency questions in page 6, I would expect more explanation and link / relation with what is explained in the following sections (pages 10-11). Its introduction in the article is done in a very isolated way. These competence questions cover information needs that arise in this case from the nature of the manufacturing and assembly process with which links should be drawn constantly.
In addition, I have some doubts about whether the first one is formulated correctly: the ontology should respond to “What is a product production method?” or “What is ‘the’ production method for a certain product?”.

5. OHO Overview
It seems more logical to introduce the overview of the ontology, and then, the process to create it, in this order and not the other way around. Therefore, I would consider including the content of section 4.2 after the overview in section 5.
Unlike BOT ontology, the scheme in figure 1 includes generic terms that do not seem to be part of the vocabulary domain: OHO-Pro, OHO-Cost (why not just call these classes Cost or Process?). It is not usual to use in some terms a nomenclature that incorporates part of the name of the ontology (at least BOT does not, and IFC/ifcOWL use the prefix as part of the name in all of them). Could the authors somehow justify this decision? (e.g., specific vocabulary for reasoning issues?)
Page 8, lines 49-51 and continuing the next page 9: duplicate paragraph. It is the same as lines 16-26 (except for the last sentence)
On page 9, the authors begin with the description of the concepts that are part of the core. But then, they continue with other concepts that are no longer, without any type of comment or separation. It would be necessary to indicate that these concepts are represented in figure 3 from the beginning. I would also suggest somehow including in the figure the relations between these concepts and the core concepts (e.g., oho:producedBy, which relates the product to a oho:Production object) for more clarity.
I would recommend the authors to clarify a little more the dependency relation between the elements illustrated in figure 4.

6.2. Quality of the modelling
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.

6.3. Suitability for an application
This section is a bit confusing. Shouldn’t it go inside section 7, particularly, at the end of the section? (First, the demonstration in a use case, then, application). As far I understand, KBE tool is an example where the OHO ontology has been applied, as said at the beginning. “The OHO ontology was used to implement a KBE tool for cost estimation of housing projects using”
Page 15, line 32: the acronym is required for KBE tool (Knowledge-Based Engineering?).

6.3.3. KBE Architecture
Page 16, line 40: in “…as well as cost data sheets and other databases”, could the authors specify what databases they are?
Page 16, line 44-45: in “Simultaneously, the ontology has learned from the changes made in the design development”, could the authors specify how this process has been carried out?
Figure 9. The architecture of the KBE tool is not very clearly represented. Some parts of the diagram seem to describe more of a process. A more uniform symbology indicating the relations between the different elements would be necessary.
Page 16, line 49: a space is needed in “datasheets,and”

7. Application of the OHO ontology
In “In order to demonstrate the functionality of the OHO ontology, a case study of a DfMA house composed…” perhaps, to be inconsistent with the content at the end of the previous section, this section could be renamed to focus on "use case" or "demonstration" instead of "Application" (another as in the KBE tool).
Figure 10. Is too small. It should be enlarged.
Figure 11. I have some doubts about the representation. Orange arrows represent the relation “IS-A”. Blue arrows represent Object Properties, but then in the T-Box “oho-prod:Resource” is-a “oho-prod:labour”? regarding the “oho-prod:Method”, in the A-Box is “Automatic” a constant value (that should be included then in the T-Box) or an instance? It is also not clear what has been inferred. If they are properties that relate instances to each other, they should be indicated.
Page 21, lines 32-43: The paragraph is a bit confusing and imprecise. What is the input data? and what does “…those input to OHO OWL ontology…” mean? About “Explanations for the semantic reasoner (e.g., pellet) inferences is available in the justification of results that is provided as an advanced functionality in Protégé.” could the authors provide some capture / text proof of this?
Page 21, lines 38-49: it is not clear what “(an OWL to STEP generated file)” means.

5. Conclusion and discussions
The second paragraph of the conclusions provides information that might need to be included in the overview section: “OHO emerged from the ifcOWL-DfMA ontology [52], which expanded the ifcOWL ontology”. On the other hand, it is not usual to include references in the conclusion / discussion section.

References: all references are in the same format and are apparently well formatted.

Typographic errors: Not detected.

This manuscript was submitted as a 'full paper' and should be reviewed along the usual dimensions for research contributions which include:

(1) Originality
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. Authors also note that existing ontologies can be extended for cost and CO2 estimates, but instead of such extensions the approach presented here is "yet another ontology" defined from scratch. This choice is mainly justified because even after such extension, "Manufacturing concepts " would still be missing.
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.). The limitations of the ontologies considered in section 3 are not clearly discussed - section 3.5 Research gap is an attempt for doing so. Table 2 should "show" that none of the existing ontologies can be applied directly without "further ontology development" for capturing "specific aspects of DfMA". 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).
The methodology used appears to be a combination of competency questions' definitions and parts from the NeON methodology. 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.
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 ?

(2) Significance of the results
The presentation of the OHO ontology shows some lacks in ontology description languages: properties are never presented as object or data properties (just plain properties), 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)
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.
The KBE tool is not available online. The article does not provide enough details and descriptions to allow the reproducibility of the tool. It is also unclear how the OHO ontology is integrated with the KBE tool and what exact characteristics of the ontology are exploited (e.g. reasoning possibilities, class or property hierarchies, specific constraints, rules).
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.
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.

Comments:
- Why 3 anonymous classes all for defining the same owl:unionOf between oho-cost:House and oho-costPanel ?
- 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 ?
- 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.

(3) quality of writing.
The level of English is correct.

(4) whether the provided data artifacts are complete.
OHO-cost module is not available - 404 errors for https://edlirak.github.io/oho/ohoModules.owl , https://w3id.org/oho-cost#,
Prefix https://w3id.org/oho# points to https://edlirak.github.io/oho/index-en.html
Visualisation provided for oho-cost which is not available (404 on https://w3id.org/oho-cost#)