Intelligent Energy Systems Ontology to support markets and power systems co-simulation interoperability

This paper overviews relevant work regarding PES existing ontologies and presents a new ontology describing its purpose, requirements, development options. The application of the proposed ontology is demonstrated in an agent-based simulation of the local grid. In general, this paper is well written and the proposed ontology makes sense, I will recommend accepting it.

The main contribution of this paper is an ontology called the Intelligent Energy Systems Ontology (IESO).

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

The main contribution is the ontology, I consider that this submission should be rejected, and the authors should be recommended to prepare and submit a 'Description of ontology' type of paper instead. See http://www.semantic-web-journal.net/authors#types

The Related Work section (Section 2) almost only introduces work from the authors (19 self references!). As the core contribution of the paper is the IESO ontology, I consider that the Section 2.1 introducing the MAS Society is totally out of scope. Section 2.2 is more in the scope as it lists the ontologies for the Power and Energy Systems domain.
- SAREF is now in version 3.1.1. The authors should update to this new version
- EMO is first mentionned, and then described again. The section should be restructured.
- The wrong reference is used for SOSA. The authors should update to the W3C rec, or the reference to the Semantic Web Journal.
For such a section I would expect an analysis of the different ontologies in terms of the domains they cover, the terms they introduce, the way they are published, etc. The goal would be to motivate their reuse or the creation of a new ontology.

Instead of self-citing unrelated work, the authors should consider checking out what has been published in the domain, as a lot of related work is missing. To name but a few:

- Zeiler, Wim, and Gert Boxem. "Smart Grid-Building Energy Management System: An Ontology Multi-agent Approach to Optimize Comfort Demand and Energy Supply." ASHRAE Transactions 119 (2013): H1.
- Wei, Song, et al. "Multi-agent architecture of energy management system based on IEC 61970 CIM." 2007 International Power Engineering Conference (IPEC 2007). IEEE, 2007.
- Hippolyte, Jean-Laurent, et al. "Ontology-based demand-side flexibility management in smart grids using a multi-agent system." 2016 IEEE International Smart Cities Conference (ISC2). IEEE, 2016.
- Haghgoo, Maliheh, et al. "SARGON–Smart energy domain ontology." IET Smart Cities 2.4 (2020): 191-198.
- Hammar, Karl, et al. "The realestatecore ontology." International Semantic Web Conference. Springer, Cham, 2019.
- Kabilan, Vandana, Paul Johannesson, and Dickson M. Rugaimukamu. "Business contract obligation monitoring through use of multi tier contract ontology." OTM Confederated International Conferences" On the Move to Meaningful Internet Systems". Springer, Berlin, Heidelberg, 2003.
- Santodomingo, R., J. A. Rodríguez-Mondéjar, and M. A. Sanz-Bobi. "Ontology matching approach to the harmonization of CIM and IEC 61850 standards." 2010 First IEEE International Conference on Smart Grid Communications. IEEE, 2010.
- Neumann, Scott, et al. "Use of the CIM Ontology." Pacific Northwest National Laboratory (2006).
- Küçük, Dilek, et al. "PQONT: A domain ontology for electrical power quality." Advanced Engineering Informatics 24.1 (2010): 84-95.
- Gillani, Syed, Frederique Laforest, and Gauthier Picard. "A Generic Ontology for Prosumer-Oriented Smart Grid." EDBT/ICDT Workshops. Vol. 1133. 2014.

The conclusions of Section 2 that there is considerable heterogeneity among the models has not been demonstrated by the authors.

Section 3 describes the methodology for establishing and publishing the IESO ontology, then details each of the modules.
The choosen methodology is probably outdated. See SAMOD or Linked Open Terms. 101 stands for one-oh-one, not one-on-one. See https://en.wikipedia.org/wiki/101_(topic)

The IESO ontology consists of a core module that imports different modules. The authors claim the modules may be versioned, but do not describe how the versions are managed.
- What is the semantics of the version number?
- What happens if a new version of a module is released?
- The namespacefor prefix ieso: includes the version number v1.0.0. Does this means that there will be a new prefix and a new namespace if the version changes ?

The authors claim that the ontology is published according to the best practices. However they never explain what these best practices are, or justify that they actually implement them. All the modules define concepts with the same namespace , but the terms do not dereference: For example returns a HTTP 404 error.
The server seems to implement some sort of content negotiation because Protégé manages to retrieve a machine readable version of the ontology, but I can't manage to find wich is the value I need to set to the Accept HTTP Header. text/turtle, application/x-turtle, application/rdf+xml, application/owl+xml, ... and many other just don't work.

The ieso ontology contains strange datatype properties: ieso:id ieso:name, ieso:number, ieso:type, etc:
- ieso:id - The 'id' datatype property relates an object or instance with its identifier. - why reinventing IRIs ?
- ieso:name - The 'id' datatype property relates an object or instance with its name. - why reinventing rdfs:label ?
- ieso:type - The 'type' datatype property relates an object or instance with its type. - why reinventing rdf:type ?

The authors claim that most modules contain a mapping to existing ontologies. There is no such mapping online.

Actors module
There are many sub-classes of Role. Some are mutually disjoint. They are not described in the article. The article should include some example snippets of how the module is used. For example taken from the companion dataset from reference [76]

Building module:
- why is the ieso:adjoins property inverse of the ieso:intersects property
- there are many sub-classes of ieso:Building and ieso:Space. How have they been chosen ? What is the procedure if one cannot find the appropriate sub-class in this list ?
- the authors claim that the classes are directly mapped to the respective BOT classes using owl:sameAs. This is not true in the Turtle document. Furthermode, owl:sameAs is for individual equality, not for classes equivalences. See Section 9.6.1 of OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition)

Contract module:
- This module is not compared to existing ontologies. See for example https://spec.edmcouncil.org/fibo/ontology/FND/Agreements/Contracts/
- Some modules use terms (for example: module Demand-Response uses term ieso:hasRemuneration) but it's impossible for a machine to track where this term originates, or if this term is defined somewhere (ieso:hasRemuneration is defined in the Contract module)

Device module
- The Device module just copies part of the SAREF ontology in an old version, without refering to it at all.
- the authors claim that the classes are directly mapped to the respective SAREF classes using owl:sameAs. This is not true in the Turtle document.

Measure module
- It is not clear how this module should be used. The article should include some example snippets of how the module is used.

Power Transmission and Distribution
- It is not clear how this module aligns to the CIM ontology, or to other ontologies in this domain.

Section 4 introduces a case study with companion dataset, queries, rules, etc., as reference [76] with permanent Zenodo DOI. The case study is in the Energy domain, and fails to illustrate exactly how the ontologies are used. The article should be self-sufficient. It should include Turtle or SPARQL snippets, with examples of the input and output.

There is no metrics about the ontologies. It is not clear what is the maintenance plan, how one can contribute, or how widely it isused.

The authors should validate the ontologies using some of the existing and well-documented approaches. See for example
- Poveda-Villalón, María, Mari Carmen Suárez-Figueroa, and Asunción Gómez-Pérez. "Validating ontologies with oops!." International conference on knowledge engineering and knowledge management. Springer, Berlin, Heidelberg, 2012.
- Gangemi, Aldo, et al. "Modelling ontology evaluation and validation." European Semantic Web Conference. Springer, Berlin, Heidelberg, 2006.

See also the typical review criteria for ontology resources in Semantic Web conferences.

This manuscript presents the Intelligent Energy Systems Ontology (IESO), which provides semantic interoperability within a society of multi-agent systems (MAS) in the frame of power and energy systems.

The manuscript is very well written, thank you.

Major Comments
Lines 299 to 301.
The manuscript highlights a limitation identified by reference [69]. “Plus, publicly available models may also become unavailable, making our model obsolete. Furthermore, importing ontologies from cross domains may cause inconsistencies due to heterogeneous definitions of the same concepts, different granularities, among others.”
This is a significant departure from many developed approaches. In fact, reference [69] integrates existing ontologies in order to form a new ontology for a specified purpose. The approach taken in the manuscript under review is not substantiated by the work that follows in section 3.
The key weakness in this manuscript results from the absence of sufficient detail when designing the new ontology. A cohesive and comprehensive description of the requirements that the ontology must fulfil is not provided, references 45 and 46 are listed but only a surface level description of requirements is provided. This manuscript currently describes some business processes and tools but does not describe the information required by these tools in terms of objects and properties, for example: the turtle file provided at the link in footnote 9 only contains 9 properties. The sum of these information requirements would underpin the ontology.

Section 3.2: Why have you taken this approach and not just reused the BOT ontology? From a building geometry perspective the relationships are confusing particularly in terms of geometric topology. Zones can exist over multiple storeys.

From a demand response perspective, is HVAC not important? Please consider the BRICK ontology.

Case study
This section is missing the value proposition for the new ontology. Yes, the IESO ontology can be used in the ways described but how does this use case compare with business as usual? Does this IESO ontology work better in some way than the solutions that are currently available?

The case study would also significantly benefit from a process diagram that shows the full range of tools and data exchanges that occur.

Conclusion summarises the developments and demonstrator but is missing a key paragraph that describes what this new ontology does for the world. In other words how is this domain better off now that this ontology has been created and demonstrated?

Minor comments:
35: unnecessary comma between references 1 & 2.
80: wording is incorrect, “provides semantic reasoning” should change to “enables semantic reasoning”

(1) Originality:
The paper describes the Intelligent Energy Systems Ontology (IESO), which aims at supporting an interoperable co-simulation of the power system including market mechanisms. The authors proposed a so-called multi agend system (MAS) society build of different MAS and ontology-based communication. With the ontology the data models of these different MAS are defined and validation and unit conversion are supported. The approach of a ontology-based co-simulation in energy systems context is novel and promising. The used MAS and their ontologies, were already desribed in earlier papers of the authors and are integrated into the IESO.

(2) Significance of the results:
The authors give an overview over already available ontologies in the domains of interest and describe how they make use of them for their approach to support interoperability with other tools. The modules of the IESO are described detailled, mentioning the dependencies between the modules and to other ontologies. In the explanation the authors mention, that "owl:sameAs" is used for referencing other ontologies, but I did not find this in the online available version of IESO and the related ontologies.

A case study shows the capabilites for the simulation of a distribution grid with some households and market mechanisms. The data of every step of this case study and the used SPARQL queries are provided at Zenodo, which makes it very transparent. Two of the used MAS are available as web services, but the other used tools seem to be not openly available. Thus, the results can be retraced, but as the tools are not available and there is no instruction how to execute the tools, it is not possible to reproduce the case study and some questions stay open. How are the provided queries and data between the different tools exchanged? Manually or by script/TOOCC? How complicated would it be to change components of the simulation?

Additionally, an evaluation of the performance of the approach would be interesting. The case study is focusing on a quite small grid with the simulation of only one time step. Of cause, this is sufficient and suitable for demonstrating the process and ontology, but for realistic simulation of the power system large systems have to be considered. Thus, at least some considerations about the scalability of the approach for larger grids, more agents, or simulation of larger time intervals would be helpful to value the relevance of the approach.

(3) Quality of writing:
Overall the paper is written well, the approach is described in a well understandable way and figures are used to visualize it. Many figures have a quite low resolution and should be replaced by vector graphics or higher resolution source files.
Some small remarks:
- line 41-44: "... such as: ..., to name a few" doubled
- line 19: Oxford comma missing after "operation"? "simulation" instead of "simulations"?
- line 258: Is "hardening" the right word here? Maybe better "hindering"?
- figure 1: There are used two different nuances of orange and different fonts (e.g., boxes "Decision Support" and "Historic Data"). If this is deliberately, it should be explained. Otherwise it should be consistent.
- figure 1: Some parts of the figure are barely readable, even when zooming in. A vector graphic should be used or at least a high resolution source file.

Open Science Data:

(1) Organization of the file:
In the provided data file a README file is missing. The description of the case study in the paper contains references to the according files in the data, which allows to follow well.

(2) If applicable, whether the provided resources appear to be complete for replication of experiments and if not, why:
The provided data seems to be complete to allow reproducing the case study. The Power Flow Service and Electricity Market Service are also available as Web Serives, but the additional used tools (TOOCC, MASGriP, AiD-EM, SSC) seems to be not available and there is no instruction how to use the different tools to execute the case study. Thus, from my point of view, it is not possible to reproduce the case study.

(3) Assess the appropriateness of the chosen repository if it is not GitHub, Figshare, or Zenodo:
The IESO and all of it's modules are hosted on a homepage and have integrated the version number in the URL. Due to not using a repository like GitHub, FigShare or Zenodo, it seems that version management and repository-discoverability is not supported and no DOI is used.

(4) If applicable, whether created data artifacts appear to be fully included in the file:
According to the description of the case study in the paper, the data artifacts seems to be complete for all the described steps of the process.