The Open Energy Ontology (OEO) is being developed as a domain ontology for energy system modelling. To increase its usability and react to user requirements, we introduce a post-coordination extension to OEO, the Open Energy Ontology Extended (OEOX). We create OEOX as an ontology for specific energyrelated terms with a high complexity that go beyond the level of detail of the standard OEO class hierarchy. It allows for a dynamic ontology composition, enabling precise and tailored annotations for energy system data sets, requiring only minimal manual intervention or curation. In this paper, we describe the user-driven motivation for this ontology extension (Section 2). We illustrate the methodology and early-state practical implementation on behalf of post-composition patterns (Section 3). The ontological annotation of datasets in real-world applications and the usage of OEOX is described in Section 4, complemented by conclusions and summary in Section 5.
Energy system analysis is a heterogeneous research area. Researchers apply numerous computer models and a broad variety of data sets for projecting scenarios to investigate current and future energy systems. The broad variety of research questions includes the analysis of the impact of electric vehicles on power grids, the quantification of the efects of renewable energy deployment on greenhouse gas emissions, and impact assessments of energy policies on the economy.
This heterogeneity challenges the transparency, reproducibility, and interoperability of computer models and data. Approaches to overcome these challenges include applying metadata standards and ontologies. Metadata standards formalise how the provenience and structure of data sets can be described in a machine-readable way and thus enable technical interoperability of data. Ontologies formalise the knowledge of a domain by providing definitions of concepts and formalising the relations between concepts in machine-readable axioms. The combination of metadata standards and ontologies enables semantic interoperability of data.
The Open Energy Ontology (OEO) [
We develop the OEO in a manual process involving a joint discourse between ontologists and
domain experts, as proposed by [
One main application of the OEO is to provide the semantics for the Open Energy Platform
(OEP)2. The aim of the OEP is to provide an information hub for the energy system domain [
In the following, we describe our motivation for extending the OEO with composed ontology concepts (section 2), present our implementation of such composed concepts (section 3), illustrate some use cases (section 4) and conclude our work with a summary and outlook (section 5).
In the context of medical terminology (SNOMED, ICD), methods, advantages and limits of
pre- and post-coordination of terms have been discussed intensely. A high degree of
pre1Open Energy Ontology, version 2.2.0, released on 2024-03-04, https://github.com/OpenEnergyPlatform/ontology/
releases/tag/v2.2.0
2https://openenergyplatform.org
3https://github.com/OpenEnergyPlatform/oemetadata
coordinated entities in a terminology provides the users with a large amount of terms. While
in pre-coordination concepts and classes are named and defined in advance, expressions from
existing concepts are put together afterwards in post-coordination [
Examples of such specific entities can be found in ICD-10 4. It contains codes such as "V91.07
Burn due to water-skis on fire" or "T63.442 Toxic efect of venom of bees, intentional
selfharm".[
A closer look at related work shows that while [
Although our work deals with post-coordination in the energy systems domain, there are similar challenges to those described in the biomedical research domain. In addition, we have introduced an extra module for the post-coordinated expressions and their implementation, which should prevent an excess of classes in the core ontology. The SNOMED standard ontology is an upper-level SCT ontology (SCTO) based on the Ontology for General Medical Science (OGMS), but there is no further distinction into modules. The ProvCaRe Compositional Grammar Syntax is also not implemented with a separate module, but it is supported by a visual user interface to help with post-coordinating terms according to specific rules.
Energy system data can be very specific and thus also their annotation. The OEO development team is frequently approached with requests to extend the ontology with new complex terms. The requested level of detail often exceeds the one that OEO developers estimate manageable and sensible for the community. For example, ‘final energy consumption of electricity by the residential and commercial sector, excluding transmission losses‘ was requested to annotate in 4The tenth version of a medical classification list of the World Health Organization (WHO). It contains codes for diseases, signs and symptoms, abnormal nfidings, complaints, social circumstances and external causes of injuries or diseases. detail a certain dataset. OEO does not comprise this complex concept. However, it provides terminology for the partial terms ‘final energy consumption‘ and detailed sector descriptions. Furthermore, the definition of ‘transmission losses‘ is currently in discussion.
Including a large amount of pre-coordinated terms with such a high level of detail exceeds
the capacities of the manual and curated development and maintenance process of the ontology.
Since it is dificult to insert all possible combinations of terms without causing a combinatorial
explosion of terminology and losing control over the maintenance of the terms, there is
increasing interest in the use of post-coordination and corresponding tools [
Due to the demand and need for compound terms for the application of the OEO, we decided to extend the OEO. It was particularly important to us that we create a way of extending the OEO that would allow new classes to be created by combining existing OEO classes, including those that OEO imports from other ontologies, with as little efort as possible and without curation. Like this, the extension should increase usability for users so that they do not have to "compose" concepts in the metadata.
Since the development of OEO is a curated and manual process [
We are aware that there is OTTR, which supports tools for representing and instantiating RDF graphs and OWL ontology modelling patterns [11], but we have decided not to use them for now, since we are still in an early state, and create our own patterns. If the terms we want to create become more complex, we will take SHACL or OTTR into account and convert them accordingly. However, we only make this decision after the testing phase.
Each entity is created as a defined class. Initially, there are two types of classes allowed: quantity values and units. Both are essential for the annotation of energy system data sets. Further options for combining terms may be added in the future.
The OEO itself imports a set of units from Units Ontology (UO) [12]. However, the imported units are not suficient and not specific enough for the use cases of OEO. Especially the annotation of datasets via the OEMetadata requires a broad set of composed units. Furthermore, some of the required units go beyond pure physical units and are thus not available in UO, e.g. information related to currencies. These and some frequently used composed units are already introduced in OEO itself. OEOX should provide the opportunity for users to annotate data with custom units from their energy system models.
For the unit composition and post-coordination, we introduced a set of object properties in OEO to be able to relate diferent units to each other, see Table 1. These object properties allow for more complex units.
The following pattern describes the constraints6 for post-coordination of units in OEOX: 1. create new defined class 2. as SubClassOf uo:unit 3. with one or multiple of the following optional partial axioms, connected via and • 'oeo:has unit numerator' some oeo:unit • 'oeo:has unit denominator' some oeo:unit • 'oeo:has prefix' some uo:prefix 4. the logical and between the combined unit numerators and denominators indicates a mathematical multiplication thereof The relations of Table 1 used in the above-mentioned pattern allow for a post-coordination for all relevant units in the context of energy system analysis. Usually, units of higher order than ± 3, or fractional order, are not needed in energy system modelling. Therefore, the decision was made to introduce the units’ magnitude explicitly as separate relations. On the other hand, a broad range of prefixes is needed, which are imported from UO. They can be related to units via the relation has prefix .
Listing 1 shows a typical unit example for energy system modelling: 2ℎ , which indicates an annual energy consumption per area. It is composed from meter, year, and watt-hour, which are all imported into OEO.
MWh/ ( m^2 a )
Megawatt − h o u r p e r s q u a r e m e t e r and y e a r
To quantify entities, especially for the annotation of data sets, OEO uses the concepts of quantities and quantity values, based on [13]. Here, a quantity is a „property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference“ and a quantity value is a „number and reference together expressing magnitude of a quantity“. Quantity values are required in order to annotate data by assigning a magnitude in the form of a number and reference (unit) to the quantities of an entity. To address this, we added the classes quantity and quantity value to OEO.
For example, the question of how much CO2 is emitted in a certain industrial process should be evaluated. This requires a specific quantity value that captures the amount of CO2. The same happens with other technologies and corresponding quantity values. Adding specific quantity values of higher complexity directly into the OEO for all required entities would be beyond the scope of the ontology. The post-coordination tool for extending OEO allows to create quantity values such as "CO2 emissions from industrial processes" and even more complex constructions. This enables using them for energy system modelling evaluations and annotations. Quantity values should be specifiable in OEOX by relating them to certain sectors, technologies, energies, commodities, systems, artificial objects, or processes. Furthermore, a combination of several quantity values might be required, for example, to create quantity values corresponding to the complex units that are created in the use case mentioned above. As the relation between the concepts, the primitive object property is about is used.
The following pattern describes the constraints7 for post-coordination of quantity values as OEOX classes: 7Note that the here described constraints will be converted to SHACL or OTTR. 2. as SubClassOf 'oeo:quantity value' 3. with one or multiple of the following optional partial axioms to the mentioned classes or its subclasses, connected via and • 'iao:is about' some 'oeo:quantity value' • 'iao:is about' some oeo:sector • 'iao:is about' some oeo:technology • 'iao:is about' some oeo:energy • 'iao:is about' some oeo:commodity • 'iao:is about' some ro:system • 'iao:is about' some 'oeo:artificial object' • 'iao:is about' some bfo:process
In this manner, it’s possible to post-coordinate a class "CO2 emissions from industrial processes" and other complex terms in OEOX, as demonstrated by the following three examples.
(1) "CO2 emissions from industrial processes" can be created as subclass of the quantity value emission value, combined with the processes CO2 emission and industrial process, see Listing 2.
(2) Another example is "final energy consumption of electricity by the residential and commercial sector": it can be built as a subclass of final energy consumption value, combined with power generation technology and household and commercial sector, see Listing 3.
(3) An example of combining two quantity values into a new one is given in Listing 4. It refers to the use case Table 2 from Section 4: To describe "maximum power capacity", the quantity values developable stock potential and power capacity are combined.
' CO2 e m i s s i o n s v a l u e from i n d u s t r i a l p r o c e s s e s ' E q u i v a l e n t T o ' e m i s s i o n q u a n t i t y v a l u e ' and ' i s about ' some ' CO2 e m i s s i o n ' and ' i s about ' some ' i n d u s t r i a l p r o c e s s '
' f i n a l e n e r g y c o n s u m p t i o n o f e l e c t r i c i t y by t h e r e s i d e n t i a l and c o m m e r c i a l s e c t o r '
E q u i v a l e n t T o ' f i n a l e n e r g y c o n s u m p t i o n v a l u e ' and ' i s about ' some ' power g e n e r a t i o n t e c h n o l o g y ' and ' i s about ' some ' h o u s h o l d s e c t o r ' and ' i s about ' some ' c o m m e r c i a l s e c t o r '
The restrictions we have defined for the implementation of new classes in OEOX are intended to facilitate the addition of new classes. Therefore we provide a predefined structure to keep the number of possible combinations of terms manageable and to exclude meaningless combinations from the very start. However, our selection of available axioms for quantity values is still broad, as there are many possibilities to combine them. We are aware that terms can be composed diferently and that our restrictions do not yet completely exclude duplications or inconvenient compositions. It is thus possible that inconsistencies occur because the extension is not curated.
We have therefore incorporated a testing phase to see to what extent duplications, inconsistencies or problems arise due to a lack of constraints. The testing phase stipulates the implementation of at least 50 unanalogous post-coordinations of terms from the collection of requested terms from SEDOS and IAMC. After the testing phase, we will assess if and to which extent we have to restrict further or diferentiate the post-coordination patterns to minimize duplications or inconsistencies. This process is intended to improve the application and use of OEOX and make the formation of new classes more efective and specific.
To allow users low-threshold access to populate the OEOX with custom entities on the fly, we are about to create a user interface on the Open Energy Platform. It will guide the users to create new entities by suggesting possible combinations by means of the predefined patterns. The new entities will be automatically completed by the tool. They will receive a semi-randomised IRI. The tool will create a human-readable definition and a label on behalf of the equivalent axiom. In addition, users will be invited to add more readable and linguistically more mature alternative labels and definitions.
In the following section, we sketch out practical annotation problems on two example use cases. We then illustrate the technical basis for describing tabular energy data and user adaption in practice. And finally, we share lessons learned from annotation activities.
The first example use case is the research project SEDOS which aims to improve the representation of sector integration in energy system models and to make the models more comparable by means of open data. Moreover, the project aims to jointly develop an open reference data set including documentation of sector integration in energy system models for Germany. Examples of missing concepts for SEDOS were: "rotor diameter of nearshore vertical wind turbines"; "warm water energy share of commercial large existing building"; "maximum value of connection capacity for uncontrolled fleet" . The lack of suitable OEO concepts resulted in a decreasing commitment to ontologically annotate data. Additionally, at the project start, there was no user-friendly workflow in place to annotate the data. Despite the established workflows and tools, the annotation remains somewhat subjective due to energy modellers’ individual understanding of their domain. The harmonisation of concept understandings within SEDOS has been achieved with several discussion sessions to establish a harmonised view of the concepts across each sector.
The second example of the broadness of energy modelling data and the need for specific concepts is provided by the Integrated Assessment Modeling Consortium (IAMC) data template, which was used in another OEO-related project, LOD-GEOSS. The template provides a standardised data format for energy modelling exercises and a nomenclature for model variables and energy data. It has been widely used since its creation in 2009. For this model, concept specificity is achieved through the concatenation of primary concepts, e.g. "Secondary Energy|Electricity|Biomass|w/ CCS"
Both examples use cases provided us with a collection of required ontology terms, which can be found in the OEOX GitHub repository, see issue #4 and issue #7. These collections served us to specify the post-coordination patterns in the first place and for an evaluation after the testing phase.
The metadata standard OEMetadata (OEM) v.1.5.1 is used to annotate tabular energy modelling datasets on the OEP and in SEDOS, allowing for ontological annotation of datasets. The graphical interface OEM builder improved the annotation workflow and increased motivations for annotating data, in SEDOS and other projects. The linkage of data and ontological concepts in OEM consists of three elements: 1. user-defined parameter name, 2. human-readable ontological concept name and 3. Internationalized Resource Identifier (IRI).
Table 2 exemplifies a dataset for wind farms, that should be annotated with OEM. For specific geographic regions and certain years, the table provides data for the installed capacity of wind power (column capacity_p_inst), for the maximum power capacity that could be installed in that region (column capacity_p_abs_new_max) and the technical lifetime of wind farm (column lifetime).
Ontological annotations can be added either in a column header or as column value when dealing with tabular data. Within the OEM standard, parameters in the column headers are annotated in the isAbout key and parameters occurring within a column are annotated in the valueReference key, as shown in the table’s metadata.
The OEO currently lacks a fitting concept for the column capacity_p_abs_new_max. However, helpful metadata comprises an ontological representation of all column headers and column parameters. As shown in Section 3, Listing 4, it can be easily built within OEOX. Facilitating knowledge difusion from domain experts to the Open Energy Ontology is paramount as a community-developed ontology. Establishing easy-to-use processes for non-OEO experts to incorporate their domain knowledge and make definition suggestions of yet missing concepts not only enriches the ontology but also promotes wider dissemination of their domain-specific expertise. This approach supports the extension of the OEO beyond the creation of additional OEOX classes. To ensure the efectiveness and longevity of dataset annotations, we need clear technical requirements for the annotation process of composed and comprehensive concepts. The integration into a suitable metadata structure supports the workflows for energy domain experts. Empowering annotators with minimal technical training is crucial for their independent and eficient annotation activities. Through the implementation of user-friendly interfaces, the annotation process can be better navigated. The development of an "Annotation Wizard", embedded within user-friendly interfaces, has proven already to play a pivotal role in enhancing the overall quality of ontological annotations. It will streamline the annotation process and also ensure that domain experts with limited expertise in ontology and metadata can actively contribute to the annotation task.
Since there is a need for detailed terminology in the energy system domain, we created the post-coordination extension for the OEO, namely OEOX. It extends the OEO with composed ontology concepts and simplifies the creation of new classes by combining existing OEO classes to increase their usability and accommodate the evolving user requirements.
However, there are some challenges that we face: The development of the OEO and its
extension is an ongoing process. OEO still lacks some relevant terminology. This implies
that these terms are not (yet) available for post-coordinations, either. OEO was not originally
developed with the goal of allowing post-coordinated annotations. This necessitates structural
changes within OEO to improve the applicability of post-coordination, including, for example,
the addition of axioms and the harmonization of quantity values. Because the OEO uses
the upper-level ontology BFO [
Despite all challenges, OEOX will contribute to the usability of OEO for the energy system community. And we will improve it further: To facilitate the access, we plan to incorporate a composer tool on the OEP to guide users to create post-coordinated terms, which will be added directly to OEOX, e.g. via the OEMetadata builder. After a testing phase, we plan a further refinement of the post-coordination patterns. Like this, OEOX, created as a user-friendly extension of OEO, will allow for more semantic interoperability and transparency of data for energy system modelling research.
We wrote this paper as part of the research projects SIROP – Towards Scenario Interoperability (grant number 03EI1035), SEDOS – The importance of sector integration in the context of the energy transition in Germany – modelling with a national open source reference energy system (grant number 03EI1040), and Stadt-Land-Energie – Robustness and applicability of inter-municipal energy transition scenarios in the urban-rural nexus (grant number 03EI1051). The three projects are funded by the 7th Energy Research Programme of the German Federal Ministry for Economic Afairs and Climate Action (BMWK). W e thank all members of the OEO and the OEFamily development teams. Without their contribution, this paper would have been impossible. Informatics 45 (2012) 199–209. URL: https://www.sciencedirect.com/science/article/pii/ S1532046411001687. doi:https://doi.org/10.1016/j.jbi.2011.10.002. [11] M. G. Skjaeveland, 2024, Ottr, URL: https://ottr.xyz/#Appendix. [12] G. V. Gkoutos, P. N. Schofield, R. Hoehndorf, The units ontology: a tool for integrating units of measurement in science, Database (2012). doi:https://doi.org/10.1093/ database/bas033. [13] BIPM, IEC, IFCC, ILAC, ISO, IUPAC, IUPAP, OIML, International vocabulary of metrology — Basic and general concepts and associated terms (VIM), Joint Committee for Guides in Metrology, JCGM 200:2012. (3rd edition), 2012. URL: https://www.bipm.org/documents/ 20126/2071204/JCGM_200_2012.pdf/f0e1ad45-d337-bbeb-53a6-15fe649d0f1.