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.
Pro:
- 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
Contra:
- 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?
|
