Rightsizing HVAC components using an ontology-driven Common Data Environment

The manuscript presents an ontology-driven common data environment (CDE) which supports the interoperability between BIM and BEM tools and aids the HVAC design using rightsizing method. The application of the ontology-based CDE for the HVAC design is demonstrated using three HVAC design cases in a real-world building project. The authors also present a roadmap on how the ontology-driven CDE can be extended to cooperate with manufacturers data storage to further support the HVAC design process in building projects. The work presented in the manuscript is interesting for the audience of the journal. It demonstrates the use of ontology and the semantic web technologies for a real-world problem in the AEC industry and the modular ontology developed in this work can be useful for other applications as well. The results from the work can further promote the use of the semantic web technologies in the AEC industry which currently is evolving towards to the BIM level 3. However, the manuscript needs major revisions to be accepted for publishing. The comments are given as below.

The comments on Section 1
- This section spends the main text to introducing HVAC design and the rightsizing methods for the design. The challenge to be addressed by the ontology-based CDE, i.e. the lack of seamless data exchange and interoperability between BIM and BEM, is not well presented.
- What is the CDE in this context? What does the data space of this CDE consider? and who are the stakeholders?
- It is unclear why "seamless data exchange between BIM and BEM tools" is important for using rightsizing methods.
- Considering the primary audience of this journal, who have limited knowledge of BIM, BEM and their data exchange, the introduction to the concepts is quite minimal. This makes difficult to grasp the underlying challenges and understand why ontology is a solution.
- what are other or current solutions to support the interoperability between BIM and BEM tools? Why ontology-based solution is preferred in this work?
- It is strange to consider ontology as a data format.
- What does mean by "interlinking ontologies" in this context? If BOT, FSO and FPO are insufficient to represent relevant dynamic properties, why interlinking ontologies can address the problem?

The comments on Section 2
- lacks a discussion on the state-of-art in the field of ontology and the semantic web technologies for CDE.
- What is the main contribution from this work compared to the authors' work on ontology-based common data environment presented in [28].
- How the interoperability is supported by the commercial CDE platforms? although data loss might happen. Be more specific, in what way IFC and bgXML are used for interoperability between BIM and BEM tools, and why IFC and bgXML cause data loss? And also, what kind of data loss? Currently, it is hard to grasp the underlying challenges to be addressed.
- What does mean by "narrow expression range"? Can this be addressed by ontology-based slution.
- It is strange that the authors state ontology as an alternative data format to address the problems. Ontology is not a data format. An ontology is a conceptual model, formal representation of knowledge in a domain of interests.

The comments on Section 3
- This section presents the domains from which the information required for HVAC design and interlinking of existing ontologies and new concepts or terms developed when they are missed. However, it lacks a methodology for establishing interlinking and developing the new concepts and terms. This makes it hard to evaluate the quality of the resulted ontology.
- unclear the coverage of the existing ontologies, and the number of new concepts and terms.
- The resulted ontology is not publicly available. very strange that the namespace of the new concepts or terms is located on a temporary server https://example.come/ex# and https://exmaple.com/inst# .

The comments on Section 4
- The ontology-driven CDE is to address the interoperability between BIM and BEM, however, unclear where BEM and BEM tools locate in the CDE presented in Fig 2?
- As I understand from the description in this section, the ontology-driven CDE aids both simplified sizing methods and rightsizing method, why the title of the manuscript focuses on rightsizing methods?
- It is quite heavy for the audience of this journal to follow all the details of both the simplified sizing and rightsizing methods in the three cases.
- From the cases presented in this section, unclear how the interoperability between BIM and BEM is addressed by ontology, or ontology-driven repository.
- How the transferring between input/output parameters and ontology-driven repository are done?
- unclear what the role ontology plays in the process.
- How is this data storage implemented? Does it use one kind of graph databases?
- How are the queries constructed? using the ontology?
- Unclear why is this centralised data repository necessary? Is an ontology-driven query interface enough to support this HAVC design process?

The comments on Section 5
- KPI1: Why is the overheating hours (Fig 6) visualized for the simplified method?
- KPI2: how does "the parser from the Semantic HVAC Tool" do the translation? What is this semantic HVAC tool?

The comments on Secton 6
This section needs to be written accordingly when the previous sections are revised. The discussion limitation should focus more on the use of the semantic web technologies and ontologies, which is more interesting for the audience of this journal.
- What are the step 4, 5 and 6 mentioned in this section.

This article presents an application of the semantic web to the rightsizing of HVAC systems in buildings. The paper claims it interfaces four tools through a centralized semantic repository: (1) the BIM model of the building, (2) a hydraulic calculation engine, (3) a building simulation engine, (4) a data visualization tool. The overall architecture is called a "Common Data Environment".

The paper should be evaluated against three dimensions: (1) originality, (2) significance of the results, and (3) quality of writing. Unfortunately, it falls short on each of the dimensions, I can therefore only recommend rejection.

1. Originality

First, the main contribution of the paper is not really original, especially considering it as submitted to the Semantic Web Journal.

The most complex part of the paper, related to the Semantic Web, is an attempt to represent building data with a collection of terms from existing ontologies, and some basic SPARQL queries. There are many technical issues with this part, see below.

Then the paper claims it feeds different softwares with the result of queries evaluated over representations of building data, and compute more things from the output. Most steps in the process seem to remain manual, as no automation script is mentioned or available from the supplementary material. Therefore, it is not clear what Semantic Web technologies actually bring.

Algorithm 1 is not implemented, or available from the supplementary material, the experiment cannot be reproduced easily. Results are not available. There is no demonstration of the approach or the visualization software.

2. Significance of the results.

The significance of the results is very limited, due to technical issues, missing information, or unreproducible results.

From Figure 1, I see many issues:
* time:inXSDDateTime is deprecated, and its domain is time:Instant. It does not apply to caso:State
* "PPM"^^xsd:decimal is ill-typed
* typo in some concepts, ex. dco:CO2Concetration in Figure 2, ex:hasCO2Concetration in Listing 1,
* a time:instant should not have two different values from time:inXSDDate
* inst:CO2-1 is the identifier of two things.
* bot:isPartOf does not exist
* fso:transfersHeatTo is wrong direction I assume
* I don't understand why fso:PressureDrop has value and unit, and caso:hasState some caso:State with some other value and unit
* MoistureCapacity, HeatCapacity, and CO2Capacity have unit kg/h
* time:minut does not exist

In Figure 5 the "Simplified" bar (970 PPM) is higher than the "Accurate" bar (989 PPM). That last one alone let me believe the research behind the paper is not serious at all.

The visualization of the result could be a drawing that has been manually edited, or not, I can't tell.

The conclusions of the paper are bold and haven't been demonstrated at all:

The first claim is "we showed how ontologies can provide flexibility and modularity for linking and extending heterogeneous data models, thus enabling semantic interoperability across different domains and applications." This is a bold statement as flexibility and modularity have not been used or demonstrated. existing ontologies have been used together, that's not really breaking new ground.

The third claim states "this approach promotes a shift towards a data-centric method, centralizing all relevant data in a single, accessible, and interoperable format. This shift not only substantially improves data accessibility, quality, and consistency, but it also establishes a trustworthy source that all stakeholders can rely upon, lowering the barrier to [...]". Note in Semantic Web there is "Web". And claims about how *centralization* improves accessibility, quality, and trustworthiness, is simply not convincing.

The supplementary material, available on Zenodo, consist of very large data files, with no README file that explain how the files are to be interpreted. They don't allow for the reproduction of the experiments. There is no excerpt of the Turtle files that Figure 1 could be an illustration of.

3. Writing

The term "Common Data Environment" is not defined. It seems like an attempt to contribute to the popularization of a buzzword from the building information modeling domain, for when simpler words could suffice.
Similar, the term "ontology-driven data storage" is overly complicated.

The paper seems not to have been proofread. As most obvious examples: a reference to a section is missing in Sec.1.2; extraneous "m" after the last sentence of section 2.2; missing prefixes op and oum; some ontologies lack a reference; typos in queries of Listing 1; in Figure 5 the "Simplified" bar (970 PPM) is higher than the "Accurate" bar (989 PPM). That last one alone let me believe the research behind the paper is not serious at all.

The semantic HVAC tool referred to in 5.3 has not been introduced it seems.

The paper aims to study how ontologies can support the task of rightsizing HVAC systems for buildings. The authors point out the lack of interoperability between BIM data and building energy system data, and claims that ontologies can solve these interoperability issues. While the aim is interesting and it seems like a good use case for ontologies, unfortunately I find that the paper has some shortcomings that results in my suggestion to resubmit the paper in another form.

First of all, the paper is submitted as full research paper, but it is not clear what the main research contribution is. While the application of ontologies to this specific use case might be novel, the application described and the evaluation as it is outlined now in the paper does not really provide any new knowledge for the semantic web community and research field. Hence, in my opinion it does not warrant a publication as a full research paper (where originality and significance of the research results are the main review criteria). Therefore I would suggest one of the following options to the authors; (1) consider submitting the paper to a journal in the field of BIM, energy management, or sustainability, where the application of ontologies to this problem may be seen as novel research results, (2) shorten the paper and resubmit it to SWJ (or a related conference) either as an “application report”, or reframe it and focus on the ontologies only, which might fit the submission SWJ category “descriptions of ontologies”, or (3) extend the evaluation to really study the contribution of the ontologies in this use case, e.g. by isolating the use of the ontologies from the extended algorithms, so that the contribution of the technology for data integration can be studied in itself. Regarding the suggestion (1), to me it seems that this is actually the target of the paper right now, i.e. the development and evaluation of improved rightsizing methods, rather than the evaluation of an ontology-driven data environment, so this would probably require the least effort. The authors evaluate the proposed method against simplified methods that are used today, but the evaluation does not specifically show what the contribution of the ontology is in all this, or whether it is actually the algorithms that are improved and that’s what makes the difference. For the other options the authors need to be very careful to point out the novelty and contribution of the approach, for the targeted community.

In addition of the problem regarding lack of contribution, I also find the general story of the paper to be a bit confusing. Rightsizing is the main target of the paper, as stated in the title and introduction, however, later on the evaluation applied the proposed methods and tools on a use case of an existing school building. I fail to see how this can show that the method is applicable when simulating new houses. How and from where would similar data be available at the planning stage?

Further, it is not clear what the authors have actually built. Is it a new ontology? An extension to existing ontologies? Or just applying existing ontologies together, and adding some algorithms on top? Early on in the paper the authors say that existing ontologies are not enough to model the domain, but then say that their contribution is to combine them - how does that add up? If the existing ontologies do not cover everything needed, then how can you apply a combination of them without extending them? This is not clarified by the details in the paper, where the illustrations seems to be using a mix of concepts and properties from many ontologies, including ones that may not even exist, or are just examples (see detailed questions below). The

ontology/ontology integration is also not motivated by any requirements presented, which leaves the reader wondering why some modelling choices are made. For instance, why do you need a caso:State related to the weat:WindSpeed and/or the dco:CO”Concentration instances, and not just directly add the value on the wind speed node or the CO2 concentration nodes respectively? I guess you for some reason want to capture the concept of wind speed in a certain location, separately from the wind speed in that location at a certain time, but since there are no requirements listed I have no idea why you want to have a separate instance for the wind speed itself (and in fact, in Figure 1 I wonder why the instance of weat:WindSpeed and bot:Site has the same URIs, perhaps this is a typo). Related to the pressure drop there is an example of having data directly related both to the pressure drop and the state nodes, however, I fail to understand what this means. What is actually a pressure drop, which is without any time relation? In the text, you indicate that it is something like a capacity, but shouldn’t that be a property on the radiator then rather than the pressure drop instance? Overall, I would strongly suggest to separate the description of the integrated model, i.e. ontology, and the data. A data example, like in Figure 1, makes sense, but not without first describing the overall model, and why it is built/integrated in a certain way.

Some detailed issues and questions regarding the paper:

- Why are BOT, FSO and FPO not sufficient for the mentioned use case? What is actually missing? You need to analyse related work more in detail, to show exactly what gap (in the ontologies) you are filling here.

- One of the research questions is whether the needed properties can be covered by interlinking (whatever that means? integrating? aligning? extending?) existing ontologies or whether a new ontology is needed. However, this is not really discussed and studied in the paper. Instead the authors simply go ahead and build something, based partly on the existing ontologies.

- Section 2.1 lacks several references to all the tools and methods related to BEM.

- Section 2.2 does not really make it clear if the problem with data loss is really a problem of expressivity in the tools (i.e. what can be modelled and stored) or if it is a problem of usability and that users are not able to correctly transfer data between tools (i.e. the tools allow the data to be expressed, but users are not able to do it, e.g. due to usability of the tools or something else).

- In the same section you also say that existing ontologies are not sufficient, but that interlinking them will solve the problem. See also discussion previously in this review, but this needs to be expanded and explained - what are exactly the gaps, and if there are really gaps, how can just linking ontologies solve it? Don’t you need to extend some ontologies? And additionally, what exactly does “interlinking” mean here?

- Figure 1 needs a legend, not only explaining the colored areas, but also the notation of the figure. I assume this is a kind of RDF graph, where in addition the blue boxes on top of some nodes illustrate the rdf:type relation to some ontology class? This needs to be made explicit. In addition, there are namespaces in the figure that are not in Table 1, e.g. dogont:, oum:, and ex: (is the latter an existing ontology, or just examples of possible properties?). Are any of the latter actually your own extension to the existing ontologies? If yes, it should be published under a permanent URI which is shared in the paper.

- In section 3 it is not clear where the data is expected to come from, i.e. is the data entered manually, or retrieved from some existing system or API? If data is not originally in RDF, how is the mapping expressed and executed? Do you use RML for instance? Weather data I assume you can retrieve from some APIs of weather

services, is that what you mean by “weather files”? If there is a large amount of manual work involved in data entry, that would reduce the feasibility and usefulness of the approach, since that raises the question: why not immediately enter the data into the simulation tool directly, why take the detour with annotating it with an ontology?

- Overall, the evaluation setup is poorly described. The tools used are not described in detail, nor is the process, i.e. what parts are manual and what is automated in your tool chain? Further, some of the measures used seem vague to me, for instance, how can indoor climate be a KPI, how do you measure that? In the introduction to 4.1 you say that you aim to determine and visualise the indoor climate, but what is the measure of success here on which you compare the methods? Usability? Or some sort of accuracy? Section 4.1.2 also completely misses any details, i.e. on the algorithm, tools, and data used.

- Overall, it is also not clear where the proposed algorithms have been implemented. Inside the tools mentioned? In a stand-alone tool connecting existing tools? Or not at all?

- In section 5.2.1 you retrieve the maximum CO2 level in the knowledge base through the query in Listing 1, but then in Figure 5 you visualise the yearly maximum, which is not a criteria in the query.

- The conclusions of the paper in section 7 match the results, but has nothing to do with the research questions, including the aim in section 1.5, which was about more efficient data management, and demonstrating the advantage of an ontology-driven CDE.