EEPSA as a core ontology for energy efficiency and thermal comfort in buildings

The paper introduces a core ontology for thermal comfort in buildings, and energy efficiency data in general. The paper presents an extensive survey of existing ontologies covering part of this domain, then proceeds to present the ontology engineering methodology used and three ODPs developed for structuring the ontology, the actual ontology in terms of a set of modules, and finally a use case where the ontology was specialised and used.

The paper is very well written and clear, and both methodology-wise and in terms of its results the paper is quite interesting. I believe that the paper has potential impact in three different ways: (i) describing a set of well-engineered and useful resources that can be reused by others, i.e. both the ODPs and the core ontology, (ii) describing a case of ontology engineering that applies various reuse techniques and firmly relies on an established methodology, which could act as a "model case" for others wishing to do a similar development, and finally (iii) making a very thorough review of related work and resources in this area it also acts as a nice comprehensive survey of the domain. The paper also fits perfectly to the topic of this special issue to which it has been submitted.

However, there are some issues as well. Mainly that the paper if fairly long, and contains maybe too many details. The survey of existing approaches for instance constitutes almost the first 12 (!) pages of the article, which is way more than a usual survey of related work in a research paper would cover. Also the descriptions of the ODPs and ontologies contain many details, maybe too many details. For the latter, it would be possible to move some details into the appendix, or even to an extended version of the article published as a white paper/technical report, or simply as part of the ontology documentation. In fact, all these details also obscures the main message of the paper a bit, and the motivation for why this ontology is constructed. I would suggest to add a more focused summary of the shortcomings of all the existing ontologies, leading up to the decision to create the new ontology (and ODPs). Currently there are such motivations here and there, but it is hard to get the overall picture. Section 2.4 is something in this direction, but it more summarises the discussions made before in each section, rather than to list all the concrete motivating factors and explain how this work differs from that which is surveyed.

Overall, I have a bit of trouble fitting this paper into one of the submission categories of this journal. The submission category according to the paper is "full paper", which would be a full research paper. The paper does not really have the character of a research paper, but rather of a combined survey and ontology description paper, which are two other categories. For a research paper I would expect more focus on novelty and contribution to the state of the art in the research field. Still, it does contain some substantial technical evaluations of the ontology and an application case where it has been used, which is what I would expect from a research paper. So it is a bit hard to make a clear recommendation for the paper. I think that everything that is in the paper is valuable and worth publishing, the question is if it all fits in this article, and how the article can meet the requirements of a certain submission category.

To make some concrete suggestions, I think that there are several options: The paper could be split into two, one survey paper and one ontology description paper. Both parts could also just be cut considerably and the details put into an extended online technical report. Or one could cut just one of the parts, and make that a technical report, while keeping most of the content of the other part and perhaps move that paper to a more appropriate submission category. In any case, unfortunately I think this paper needs a major revision before publishing it, since it does not completely fit the journal requirements of the submission category.

Some additional detailed comments/questions:

- Overall the language of the paper is fine, but there are some paragraphs that need improvement. For instance, the end of the second paragraph on page 2.

- Please also consider the structure of the survey part of the paper, e.g. the order in which the ontologies are presented. Sometimes the text refers to sections later in the paper for explanations, which is not very good. It would perhaps be better to present the more basic ontologies first, and then those that build on them. Similarly, section 2.2 seems to be a bit of "the rest" in terms of presenting both domain ontologies as well as general ontologies about time, space, provenance etc. I would suggest to split that section into at least two parts.

- To improve the readability of the survey part (if this is kept in full length) I would also suggest to insert some kind of overview, e.g. a figure or table. A table listing all the ontologies (at least the domain-focused ones) that shows some important characteristics of each one, as well as their differences, would be a nice addition.

- The first concrete example in the paper appears in section 2.3.3. Examples are a good tool to illustrate capabilities and differences between the ontologies. So if the survey part would be broken out as its own paper I would definitely suggest to add at least one example in each section, i.e. for each ontology. However, in the current paper it is rather the opposite, that things need to be cut, hence, the authors should consider if this example is really essential.

- Final sentence of section 3.1: I think this highly depends on the modelling style and structure of the data, so it is not necessarily the case that this is represented by one single property in all datasets.

- I am not sure that I really agree with the discussion on intrinsic properties on page 14. The example given says that the temperature property is not intrinsic, since it is used for two different individuals. To me this does not contradict being intrinsic. The property is intrinsic to the class of individuals, to each separate individual. So to me the fact that temperature is intrinsic to room, i.e. the temperature of a room cannot exist by itself it is always dependent on the room (or even more general, of the location where temperature is measured), is perfectly ok. Maybe I missed something here, but then the authors need to explain the issue better, or in a different way.

- When describing the ODPs the terminology, mainly of the property names, differs quite a bit from the ontologies that they are aligned to. This is not really discussed in the paper. Although naming of elements in an ontology (or ODP) does not really affect the logical capabilities of the ontology, it is still an important aspect from a usability and understandability perspective. Hence, in my opinion, there should be a clear motivation for choosing different terminology than that of already established ontologies.

Relatively little attention to the actual KDD.

Little attention also to software supporting the ontologies.

Maybe put existing ontologies in matrix with key characteristics like context (residential, commercial , ...)

typo: "propsoed" on p.6

2.2 the linking between instance and class is typically not the linking meant when talking LD....

2.3 explain last par. (“ucum not implemented”...). I know a jena update is needed to be able to automatically compare units (as in the playground of CDT/UCUM).Was this meant?

Term used is qualities. What about quantities. Seems covered by qualities but make explicit.

2.1 BIM is not a format. A BIM is a model having a format, potentially a standard format like SPFF in case of bSI.

2.1 BIM not only gives common model to cover the whole LC.

2.1.1
iso IFC instance files normally th term STEP Files is used. Files in the format STEP Physical File Format (SPFF).

2.1 BIM may also contain dynamic info, why not? (ie operational data like whether window is open or not)

p12: order of scenarios mention? (1, 7, 3, 4)

p13: again always about qualities, what about quantities...give a good definition

p14: :temperature is an instance but its name does not suggest that! you would expect temteraure_123

At section on LBD: mention also latest development like “IFC2LBD convertor”.

General: resulting ontology is still quite complex. I would have hoped for more simplicity like:

:Space, :BuildingElement, :Device, :Sensor, Actuator
all properties modelled directly via CDT/UCUM

but ok, you need some objectivication to indicate a value is measured by a sensor....

General: will ontology be still ok for big data (ie we measure stresses for bridges at 1500HZ....resulting quickly in terrabytes of raw data). Here we really need simpler ontology! compare now: csv file.

Anyway, very relevant and good overview of IoT-like ontologies and proposal!

This manuscript was submitted as 'full paper' and will thus be reviewed along the usual dimensions for such research contributions which include (1) originality, (2) significance of the results, and (3) quality of writing.

(1) Originality:
The manuscript at hand requires major changes to become acceptable while the potential impact of this incremental work is difficult to assess based on the article submitted. The delta to existing work is quite low: all of the contributions of the article at hand are "adaptations" or "reenginnerings", "inspired" by already published approaches, even standard ones.
From the reviewer's point of view, no solid arguments have been provided regarding the need to define a "Yet-Another-Ontology" for energy efficiency, especially while standards such as SOSA/SSN or SEAS allow "different ways of modelling observable properties" and/or encourage users to contribute.
The revised version of this article should carefully examine the scientific reasons supporting the development of an ontology from scratch, while clearly specifying the advantages for doing so e.g. in terms of competency questions that are relevant for the considered domain and that remain unanswered by existing approaches.
Article's revision (if accepted by the authors) should also present a use case that allows evaluating the proposed approach in the context of the considered research problem e.g. "thermal comfort". As such, the use case discussed can also be handled with existing standard ontologies and it fails in clearly illustrating how authors' approach compares to existing ones (be it in terms of benefits, efficiency, modelling, etc.)

(2) Significance of results:
The importance of the approach presented here is difficult to assess, as it is evaluated in an application domain that is totally different than the one presented in the introduction. There is little novelty in terms of scientific contributions when comparing this paper with what has already been presented by the authors in the article http://CEUR-WS.org/Vol-2195/pattern_paper_2.pdf. The article at hand comes with an extended state-of-the-art section, but unfortunately the analysis of existing approaches isn't based on the competency questions used for evaluating authors' approach.
Introduction defines the research problem as being "thermal comfort", defined as a "condition of mind that expresses satisfaction with the thermal environment and is assessed by subjective evaluation" (according to ANSI/AHRAE Standard 55-2017). Authors further argument that "thermal comfort" has a direct impact on humans in terms of work efficiency and productivity. This being said, the use case chosen by the authors to "prove" advantages of the approach presented, is totally off-topic: the reader "jumps" from discussing human thermal comfort (how it impacts humans, how it can be assessed, etc.) to "animal health" optimization. Authors then extend the ontology previously presented in order to take into account the new application domain e.g. poultry farm. They claim it is an advantage of their ontology to be "customizable", still according to reviewer's knowledge this is an intrinsic advantage of ontologies themselves and is not proper to the EEPSA ontology. Thus the use case fails in proving anything regarding the ontology at hand and doesn't build on any of the findings and issues mentioned in the introduction. Even worse, additional state-of-the-art elements are directly inserted in Section 4 (Real-world use case) in the section describing EEPSA ontology customization e.g. CROPont ontology, Planetome, AGROVOC. These approaches should be placed in the Related Work section and characterized thoroughly, notably by applying the different competency questions considered.
Introduction and abstract claim a contribution in the area of "application assistants" supporting "data analysts" in discovering new knowledge (from databases not from semantic triple stores!). Still the article fails in describing such a contribution. It mainly describes some ontology pattern designs that are all reengineered versions of standard ontology design patterns e.g. SSN/SOSA or SEAS. The justifications provided do not suffice to explain the need for redefining existing patterns (patterns proposed are very similar if not identical to the standard ones - see arguments below). There is no content in the article illustrating how the ontology at hand can assist some "data analyst" nor how it allows to "predict" something.
Related work section contains an extensive list of ontologies developed in the fields of "building", "observations, actuations and other related domain ontologies" and "spatio-temporal and units". Unfortunately the ontologies mentioned are not evaluated against the requirements identified for the EEPSA ontology. These requirements are presented as "competency questions" and partially listed in the section presenting the contribution of the authors. These competency questions should've been used to characterize/evaluate the different ontologies considered in the Related Work section, in order to clearly point to missing elements or competency questions that remain unaddressed by current approaches. This is missing from the article at hand. The Related Work approaches are only described "literally" - an evaluation providing ontology metrics such as design correctness or structural metrics as provided for the EEPSA ontology (in section 3.5 Evaluation). A full list of competency questions is also needed since the beginning of the Related Work - presenting some competency questions for the general EEPSA ontology, then adding a few new questions per each pattern conceived is counter-intuitive. Competency questions represent the requirements for the EEPSA ontology, thus they have to be used when analysing existing approaches.
Moreover, as the contributions of the authors are in the field of ontology design pattern (ODP) definition, this domain needs to be presented or discussed. It is not the case in the article at hand.

It is also intriguing to read that while "the fact that different stakeholders adopt different modelling options may derive in interoperability problems" and "explicit alignment of terms from different ontologies as well as the mapping to upper level ontologies promotes interoperability", authors choose to define a Yet-Another-Ontology and do not comment how it aligns with existing approaches (while alignments are defined online). From the reviewer's point of view, as such, this approach is augmenting heterogeneity of modelling approaches thus going against interoperability. The revised version of the paper should correctly analyse whether the proposed design patterns are needed (analysing the limits of existing modelling patterns, perhaps in terms of competency questions they allow answering), identifying a correct evaluation scenario and then discuss and present how they are linked/aligned with standard ontologies.
Specifically, regarding the 3 ontology design patterns defined, authors fail in defining a clear rationale supporting these new patterns:
a) ODP affectedBy - the issue mentioned (seas:derivesFrom) isn't clear and is addressed in SEAS by means of seas:isPropertyOf, which "Links a seas:Property of its one and only seas:FeatureOfInterest" (https://ci.mines-stetienne.fr/seas/FeatureOfInterestOntology) so it does not need to be defined as functional. Indeed, in the context of SEAS one can define specializations of seas:hasProperties: "This is done using sub properties of seas:hasProperty, informally named property keys, that are functional properties with domain seas:FeatureOfInterest and range seas:Property." (https://ci.mines-stetienne.fr/seas/FeatureOfInterestOntology). The need for a different ODP has thus to be further justified.
b) ODP EEP also comes with an unclear rationale e.g. "to represent result-related matters" and "because it is common to include information [about results of observations and actuations] as parameters of observations and actuations" and "because there is no property directly linking sensors to features of interest" and "composition of properties that link them through the sosa:Observation class are not sufficiently constrained". This version of the article doesn't provide references for justifying such claims, nor clear examples proving the aspects pointed at. Moreover, as noted by the authors, "the proposed EEP ODP is an adaptation of the [SEAS] PEP ontology to fully satisfy the required competency questions overcoming the indicated weaknesses of SOSA/SSN"
c) ODP RC also comes without a reason for redefining sosa:hasResult (authors create a new object property called rc:hasResult) and sosa:hasSimpleResult (authors create a new datatype property rc:hasSimpleResult) properties. Moreover, authors-defined properties come with poorer semantics (according to their textual definition rc:hasResult and rc:hasSimpleResult are the same).
The following concepts defined by the authors have the same definitions as already existing concepts in standard ontologies:
- aff:FeatureOfInterest and seas:FeatureOfInterest
- aff:Quality and ssn:Property
Authors' article published at WOP 2018 already contains an extensive description of design patterns affectedBy and EEP.

(3) Quality of Writing
The level of English is good, there are no major elements hindering the overall comprehension of the paper. Remarks in this regard mainly concern adding references missing from several sentences / claims as on Page 12 "A trend towards a pattern-based design…", "Sometimes vocabularies play a similar role to catalogues".
Add references to ANSI/ASHRAE Standard 55-2017FIEMSER, SAREF4BLDG.
CQ13 (page 13) should be rephrased

Given these remarks, the reviewer is in favour of a major revision of the article at hand. The reviewer expects the following points to be addressed by that revision:
a) Present related work in the context of ontology design patterns, KDD and IoT
b) Clearly define how the conceived ODPs address the weaknesses of existing proposals - through explanations and benchmarks
c) Consider a use case pertaining to the research problem discussed e.g. human thermal comfort
d) Show an implementation / use case that allows assessing the interest or benefits of the EEPSA for supporting prediction while assisting the data analysts, present advantages compared to traditional KDD
e) Include a thorough evaluation bot quantitative (e.g. query execution times, use of reasoning, amounts of data that can be handled) and qualitative (ease of modelling, benefits in terms of expressivity, competency questions unaddressed by existing standard approaches)