Efficient management and compliance check of HVAC information in the building design phase using semantic web technologies

Tracking #: 3439-4653

Ali Kücükavci
Mikki Seidenschnur
Pieter Pauwels
Mad Holten Rasmussen
Christian Anker Hviid

Responsible editor: 
Karl Hammar

Submission type: 
Full Paper
Several OWL ontologies have been developed for the AEC industry to manage domain-specific information, yet they often overlook the domain of building services and HVAC components. The Flow Systems Ontology was recently proposed to address this need, but it does not include HVAC components' size and capacity-related properties. Also, despite their strengths in representing domain-specific knowledge, ontologies cannot efficiently identify poor data quality in BIM models. A four-fold contribution is made in this research paper to define and improve the data quality of HVAC information by: (1) extending the existing Flow Systems Ontology, (2) proposing the new Flow Properties Ontology, (3) proposing an HVAC rule set for compliance checking. Moreover, we use semantic web technologies to demonstrate the benefits of efficient HVAC data management when sizing components. The demonstration case shows that we can represent the data model in a distributed way, validate it using 36 SHACL shapes and use SPARQL to determine the pressure and flow rate of fans and pumps.
Full PDF Version: 

Major Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Joern Ploennigs submitted on 19/Jun/2023
Major Revision
Review Comment:

The paper presents a larger body of work on how different ontologies can be used to model flow properties in Heating Ventilation, Air Conditioning systems and validate their correctness.

The paper is targeting a valid problem in modelling and computing numerical parameters in engineering at the example of HVAC systems in a building. With this specific use case they are investigating a larger problem of partial nonlinear computations with semantic models and reasoning. By adding a validation rule set, they provide a way to avoid inconsistency problems in their computation.

However, they cannot fully remove the inconsistency problems automatically and often fallback to manual modelling missing parameters. This is partially caused by their detailed modelling approach, for which they do not explain the design process well and which could be simplified in the interest of usability, in my opinion. Here the paper struggles with its own extend as the authors show in few examples how things can be modelled, but, they do not explain why that should be the way to do it.

This renders the paper mainly a description of examples of the authors body of work. It still lacks a clear presentation of the novel ideas that could be replicated in other semantic web use cases that I would look for in a SWJ paper. I would advise the authors to sharpen their presentation by defining their requirements first, deriving design decisions and then focus on presenting just that.

- large body of work ranging from an extension ontology to rules to verify the properties and perform calculations, to an implementation as service with validation on a practical scenario
- the authors do not just model the flow properties, but, utilize reasoning to compute aggregated flow properties
- the authors provide a rule set to validate the correctness of the ontology in a web service. With this they provide a good end to end solution to the problem

- The ontology design of FPO is in my opinion not well argued. It is presented in an example, but, many things could be modelled in other (potentially simpler) ways. Here a better explanation of the design decisions is needed.
- The ontology is rather detailed and in consequence will be harder to use. I would recommend rethinking if all things (like Ports, Flows) are needed or if a minimal viable ontology design would suffice.
- The authors implement the validation service as microservice (for a single service problem) and again do not provide reason for this decision.
- The text contains typos and grammar errors that should be corrected

Detailed comments:
- Sec 1.3: You define as target to “investigate whether it is the best approach to create a new ontology”, How do you intent to measure that?
- Sec 1.5: What is the benefit of extending FSO with a new ontology instead of just altering FSO?
- Sec 1.6: Typos and missing spaces
- Sec 2.2: “extremely extensive schema that is difficult to extend”, repetitive
- Sec 2.2: You critique IFC as too complex and hard to extend to be useful and then state that ontologies are better. But then you present the ontologies SAREF, BOT, and FSO that are all based on IFC. So, are there good aspects about IFC?
- Sec 2.3: Compliance checking is a goal, rule-based checking a method. Further differences exist to and between code-checking and constraint checking. It is not all the same and certainly not limited to rule-violation tests.
- Sec 2.3: Why is the discussion of SMC relevant for your goal of checking flow rates in FPO with SHACL? What would change in the paper if you drop that section completely?
- Sec 2.3.1: How is SHACL dealing with the open-world-assumption in compliance checking?
- Sec 2.3.2: “None of the mentioned authors developed a SHACL-based rule model”, this is incorrect based on your own references [9,56,36,58]. They may not have done it for FPO, but, does that suffice a journal paper?
- Sec 3: How do you deal with open-world-assumption in your implementation?
- Sec 3: I am missing a classification of your problem. When you are dealing with validation problems, you normally differentiate between hard constraints and weak constraints, i.e. mandatory and optional structures.
- Sec 3: Why did you select an L2 property modelling approach? It requires more elements to model. L1 is the OWL design for properties and metadata can be modelled with annotations.
- Tab. 2: Where is this originating from?
- Fig 3: What is the benefit of modelling Ports, Flows, ConnectionPoints, Interfaces separately? You collapse them in Fig 8 anyway and only consider Segments and Fittings. The number of relationships make it harder to model it, specify SPARQL and SHACL rules and degrade their performance. My recommendation would be to keep it simple and minimalistic. If I understand you correctly, then your target is not to create a physical simulation model, but, a simple semantic representation.
- Sec 3.2.2.: Do you define any class constraints to automatically assign and/or disjoin subclasses?
- Sec 3.5: If only 14/50 and 2/50 properties in FPO align with SAREF and Brick, then you do not really align. This contrasts with your statement at the end of Sec. 1.3. Another section that could be potentially dropped.
- Sec 4: Solihin complexity should be defined here where it actually will be used.
- Sec 4.1: What is a component? How should a non FPO expert understand this example?
- Listing 1: Implements Constraint 1. Why then define the other 6?
- Listing 2: What if people use the wrong datatypes?
- Listing 2: Do you expect practitioners to write such a rule set?
- Listing 2: Why do you round demand?
- Sec 4.3: You talk about complexity, but it is unclear you refer to Solihin complexity def.
- Listing 3: Would it not be easier to materialize computed results like the pressure drop?
- Sec 5: How much of the ontology can be converted from BIM?
- Sec. 5: Are results materialized in the graph?
- Fig 10: Who should be able to do all those manual corrections?
- Sec 5.1.1.: “By clicking on a specific HVAC Component”, I clicked on it, nothing happened. Seriously, there is no image of the GUI, so I cant follow your explanation.
- Sec 5.1.2: Why microservices for a single service problem? What needs to be distributed here? What are the different services with different scale requirements?
- Table 6,7 mostly contain 0 that could be left out as they don’t add anything
- Sec 5.2.2: “approximately 0.5% of the components are violating the HVAC rule model”, no, as each rule is covering multiple elements. It is not a single instance that is faulty it is the shape (graph pattern). A correct comparison would be toward the total of the fault count plus the instance count of the graph pattern that is correct, thus TN/(TP + TN).
- Sec 5.2.2: “73% of the violating instances”, not instance, shapes
- Sec 5.2.2: “We can access Table 6 in the client by clicking on fso:System“, there is no fso:System in table 5. Please keep in mind this is not a handbook, but, a journal paper.
- Sec 5.2.2.: “All 32 violations were corrected in the data graph by performing the SPARQL”, why not directly run that before the validation check?
- Sec 5.5.2.: Is deleting faulty systems really a solution to the problem? How do you guarantee that not accidentally an important systems is deleted?
- Sec 5.2.2: “The remaining violations were corrected manually in the BIM model, parser, and data graph“, how much time did you spend on that? what skill level is required? how much indepth knowledge of the system and model?
- Sec 5.2.3.: “In the GUI the user can implement the correction of all 14 violations automatically“, how? Is he doing that in the GUI, or is he getting graph IDs like in Table 8 and then and then has to manually edit the rdf graph or find them in BIM to modify them there?
- Sec 5.2.4: but, what is the coverage of the remaining graph? How many systems were deleted? how many zones are not supported?
- Sec 5: You do not discuss what was missing from the model. You just tell me that different rules can be violated and fixed with undocumented manual changes. But, what is actually the typical missing information. Is that information that is missing in BIM, when I would do a similar calculation or that information that got lost in the transformation process?
- Sec 6.1: “This paper shows how an ontology can be extended, constructed and aligned”, this is well known and no innovation. Your presentation is missing also relevant details of the design process.
- Sec 6.2.: “We also demonstrated how separate and lightweight ontologies such as BOT, FSO and FPO can be interconnected “, you actually dont show that. you describe that it is possible, but, how much alignment exists? how many elements of the different name spaces exist? table 4-7 only list FSO and FPO elements.
- Sec 6.2.4: Why do you want to put geometry in the semantic model? What could a semantic model improve over IFC? Would IFC problems like incorrect separation not simply be transferred to the semantic model?

Review #2
Anonymous submitted on 24/Jun/2023
Major Revision
Review Comment:

This paper explores the extension of an existing ontology, the Flow System Ontology, to better address the needs of the industry by defining passive concepts such as pipes and ducts, along with the flow that occurs within them. Additionally, it aims to bridge the knowledge gaps in existing ontologies like BRICK by defining terms that can facilitate the understanding of the system's topology being modeled.

(1) Although this paper may appear original, it bears a significant resemblance to an emerging standard, ASHRAE223P. If this similarity is coincidental, it is acceptable. However, the authors are highly encouraged to further study ASHRAE's efforts in this area and elaborate on the similarities and differences, as this standard is not even acknowledged in the paper. Please provide more details on this aspect.

(2) The capabilities and results presented in this paper are highly relevant to the building industry, catering to building designers, owners, maintainers, and analytics companies. However, further discussions on the implications of the work are needed to enhance the paper.

(3) The quality of writing is commendable, demonstrating coherence and consistency throughout the paper.
(4) The authors have provided a list of GitHub repositories. However, the README files are incomplete and lack description. For the purpose of replication, all files, including SPARQL queries and SHACL shapes files, associated with this paper must be submitted in an organized manner with proper documentation. There are multiple repositories and files on the GitHub server, making it difficult to locate the ones relevant to this publication. Additionally, the Python codes that utilize the RDFlib package for validation were not found. The authors are highly encouraged to update the readme files for all the folders in their GitHub account.

Review #3
By Cogan Shimizu submitted on 15/Aug/2023
Major Revision
Review Comment:

This manuscript provides five deliverables

+ Sufficient evaluation
+ Well written

- Design methodology for FPO is insufficiently motivated or explained -- how and why were these decisions made?
- The organization and presentation (e.g., documentation and installation instructions) of the tool and infrastructure are entirely inadequate

Detailed Comments & Errata
* There are many instances of overfull hboxes
* Figure 1 doesn't seem to actually add any new insight -- as a submission to the SWJ, most readers would already be familiar with an ontology network.
* Sec 1.5: As a meta-question, why propose an extension instead of contributing back to the FSO? Is it a problem of community management, or are the extensions only worth it with an presumed use of FPO?
* Sec 1.6: Missing space in line 155
* Semantic Web is inconsistently capitalized throughout the manuscript (E.g. sec 2.2)
* Sec 2.2: What does LBD CG stand for?
* Sec 2.2: More overfull hboxes.
* Sec 2.2: This section could benefit from a more contribution focused narrative. It was a lot of exposition of ontologies, but no clear connection to why they were specifically introduced (e.g., of them, only BOT appears in Figure 9)
* Sec 2.3: Could be significantly shortened (i.e., most of it appears to be irrelevant to the paper). I could see the length/exposition remaining if it was a point of comparison (e.g., Sec 6.2.2)
* Sec 2.3.2: overfull hbox -- also, URIs are inconsistently rendered with \tt throughout the manuscript.
* Sec 2.3.2: I'm not sure if the claim "None of the mentioned authors developed a SHACL-based rule model nor performed a conformance check against an OWL-based HVAC model" is actually true. This is contradicted by the first sentence in the Section -- using SHACL to valid ifcOWL.
* Figures 3 and 4 could be improved for readability -- I realize that you want to maintain the physical relationships (consider vertical, for both space efficiency and size of text).
* Sec 3.1: These might be representative CQs, but they leave a lot to be desired from a modeling perspective. For example, I would have expected a list of CQs with complete coverage over Fig 9.
* Sec 5.1.1: It was not clear how to start the service, or what services were expected side-by-side in order to utilize the service/client/etc.
* Sec 5.2.2: Am I to understand that 340 violations needed to be fixed manually? This is significant!
* Sec 6.1: "this study implements technical solutions and demonstrates a path towards better data quality in BIM models, time savings due to computerization and increased transparency." I do not understand how this claim can be made, in particular given the above comment.