The European Union's initiative on European data spaces aims to support innovation and economic growth by facilitating secure, interoperable data sharing across key sectors such as health, energy, and mobility. Within European data spaces, high priority is given to adherence to FAIR data principles. Thus, data and services should be findable, accessible, interoperable, and reusable. Ontologies as semantic models are fundamental in achieving semantic interoperability, as they provide a common framework for data and service access, discovery, understanding and reuse. However, the inherent complexity of data space initiatives, coupled with their underlying domains diversity are key challenge facing optimal FAIRness. This motivates the need for an agile methodology that aligns with data space principles, integrates existing domain standards, consolidates the use of metadata for ontology's FAIRness, and engages various involved actors (domain experts, data service providers, ontology engineers) towards the development of common data space ontology. In the frame of the OMEGA-X project, aiming to build an energy data space, this paper presents AIME, an ontology development methodology integrating the reuse of both standards and reference ontologies to enable the development of modular ontologies for data spaces. It leverages agile principles to strengthen communication between various stakeholders through diferent steps: reference standards and ontologies selection, selection of use cases, design and selection of interaction models capturing data exchanges, ontology modules creation, automation and continuous integration features to support the entire original ontology engineering phase and reuse by data space users.
The European Union (EU) has outlined a comprehensive digital strategy aimed at fostering innovation and driving economic growth through the establishment of European Data Spaces, which are expected to ofer secure and interconnected environments that facilitate the sharing of data and services across a broad range of sectors, including energy, health, agriculture, and mobility. These shared data and services should be annotated using shared and standard metadata to adhere to the FAIR data principles—Findability, Accessibility, Interoperability, and Reusability—.
Adopting FAIRness in such a dynamic ecosystem presents significant challenges, including data,
services and stakeholder heterogeneity, the variety of use cases (UC), and the dynamic nature of data
exchanges. Ontologies and vocabularies provide valuable resources for semantic annotation and support
established data space (DS) components, enhancing data findability and reuse mechanisms.
Ontologybased solutions can be integrated with multiple DS components, such as the provision of metadata in
data catalogues for the data semantisation in data connectors and exchange layers [
Building an ontology for DS remains a very complex and time-consuming task. In addition to the
aforementioned challenges, ontology is highly sensitive to frequent updates, continuously extending the
scope of the UC and requiring a rigorous methodology to ensure ontology’s continuous development.
Using ontology development methodologies is one of the best practices in knowledge engineering,
and recent methodologies integrate agile principles to enhance collaboration and ensure the resulting
ontology quality. However, these methodologies often remain generic, with little specification of the
knowledge acquisition phase, which is essential to enlarge the scope of the ontology and, consequently,
enabling the FAIRness of the DS. Other requirements for DS poorly considered in existing methodologies
are extending considered reference resources with domain standards and ensuring standards ontology
annotation guidelines. A cornerstone component of the DS is a marketplace catalog enabling to find
datasets and services through catalogs, based on shared metadata definitions. As per EU standards,
generic metadata ontologies (such as Gaia-x 1, using DCAT 2) are widely used but do not exhaustively
cover requirements for quality and provenance metadata. Also, they provide generic keywords that do
not capture specific attributes to consider in the particular domain of the DS, such as energy or education
related. These vocabularies are extracted from domain-specific ontologies designed to cover datasets
and services content. The provision of domain-specific metadata and related taxonomies is a crucial
challenge for DS, that ontology development methodologies should address at early stages. In this
paper, we introduce the Agile Interaction Model based Methodology for European data spaces (AIME),
which builds upon existing methodologies, in particular (LOT) [
The rest of this paper is organised as follows. Section 2 provides background and derives principles for the ontology engineering methodology. It also overviews existing ontology development methodologies and assesses their compliance with identified principles. Section 3 introduces the AIME methodology workflow and highlights some outcomes of its use in OMEGA-X project.
This section justifies principles for the ontology engineering methodology, and motivates the development of a new methodology. Section 2.1 provides background on European DS. Section 2.2 describes projects contributing to the European energy DS. Section 2.3 overviews the related stakeholders, standards, and ontologies. Section 2.4 then assesses the compliance of related ontology engineering methodologies to our principles.
A DS is an ecosystem structured around agreed-upon elements, facilitating the efective and trusted
sharing of data among participants to generate value [
Europe aims to enhance its global competitiveness and foster innovation by establishing a common
European DS. This initiative facilitates data flow within the EU and across sectors, promoting the
availability, sharing, and reuse of high-quality data to drive the creation of new business models and
services while ensuring data security, privacy, and sovereignty [
The design of DS poses notable challenges such as the integration of heterogeneous data sources
in terms of syntax, format, standard, provenance, quality, etc. The quote above actually starts with:
“Standardisation and semantic interoperability should play a key role to provide technical solutions to
ensure interoperability within and among common European DS which are [...]” [6, Whereas (103)].
In particular Article 33 of the European Data Act [6, Chapter VIII (Interoperability)] lists essential
requirements regarding interoperability of data, of data sharing mechanisms and services, as well as of
common European DS. As a first approximation, the text requires that datasets and their associated
metadata adhere to the FAIR principles which means that they should be easily findable, accessible,
interoperable and reusable [
There are several initiatives and European projects actively contributing to the semantic interoperability in the Energy DS. An overview of some selected projects is depicted in the following section.
Several projects explored data interoperability in the energy sector [
Large-scale project H2020 INTERCONNECT5 developed and showcased interoperable solutions connecting smart homes, buildings and grids [13]. The INTERCONNECT ontologies rely on and contribute to the ETSI SAREF extension for the energy domain (SAREF4ENER). H2020 call DT-ICT-112019 "Big data solutions for energy" funded four projects, including PLATOON6 [14], which contributed with semantic web technologies and the SEDMOON (ontologys Of Energy) ontologies7. Six ongoing projects are currently funded by Horizon Europe to prepare the ground for the deployment of the energy DS. Five are funded by call HORIZON-CL5-2021-D3-01-01 and develop detailed UC, identify building blocks and define interoperability requirements. Among them, ENERSHARE 8 includes 7 pilots in 7 countries including local energy communities electromobility, flexibility and renewables focusing 3SEAS - Smart Energy-Aware Systems, 35 partners, 7 countries, https://itea4.org/project/seas.html 4https://w3id.org/seas/ 5INTERCONNECT - Interoperable Solutions Connecting Smart Homes, Buildings and Grids, 50 partners, 11 countries, 30 Me, GA 857237 - https://interconnectproject.eu/ 6PLATOON - Digital PLAtform and analytic TOOls for eNergy, 20 partners, 9 countries, 10 Me, GA 872592 - https:// platoon-project.eu/ 7https://w3id.org/platoon/ 8ENERSHARE - Enershare facilitates the energy sovereign and trusted data exchange, 28 partners, 12 countries, 10M e- GA 101069831 - https://enershare.eu/ on wind energy. OMEGA-X9 focuses on 4 UC families: local energy community, flexibility, renewables, and electromobility. The variety of UC addressed by OMEGA-X and sister projects, along with the dynamicity of data exchanges, raise the following principle: Principle 3 (Be UC centric). The ontology development should be driven by UC, capturing dynamic data exchanges.
The int:net coordination and support action seeks to establish an interoperability framework and an open, cross-domain community of stakeholders to work on developing, testing and deploying interoperable energy services. The development of the DS common ontology involves diferent stakeholders: domain experts, software service developers and ontology engineers. The coordination between these diferent parties can lead to backlogs of high-priority items that will be implemented by ontology engineers [15]. Therefore, the development should adhere to Manifesto agile principles to ensure an adaptive and iterative approach to ontology development.
Principle 4 (Be agile). The methodology should comply with the Agile principles.
The traditional energy grid involves diferent actors such as the energy producers, Transport System Operators (TSO), Distribution System Operators (DSO), market operators, energy regulators, and energy retailers. Recent developments such as distributed energy resources, electric vehicles, and the Internet of Things (IoT), opens the game to many more actors such as energy aggregators and flexibility service providers. The Bridge initiative brings together research and innovation projects that aim to create a structured view of cross-cutting issues in the energy sector in Europe. Bridge maintains the repository of UC from European projects, which are expressed in terms of objectives, actors, services, sequence diagrams and data exchanged, following the IEC 62599-2 standard [16]. Standards play a crucial role in ensuring interoperability, safety, and eficiency across various aspects of the energy sector. The Bridge data management working group recently published version 3.0 of the European energy data exchange reference architecture, which positions existing standards in the IEC 63200 Smart Grid Reference Architecture Model (SGAM) 3D model. IEC CIM (Common Information Model), a reference for information exchange between energy actors [17], consisting of IEC 61970- 3XX and IEC 61968-11, is largely used by utilities for modeling energy-related information. CIM is UML-based but possesses a representation in RDF. IEC 61850 (Communication networks and systems for power utility automation) defines a communication protocol for intelligent electronic devices at electrical substations [18]. IEC 62056 (Device Language Message Specification DLMS-COSEM Companion Specification for Energy Metering) defines an object-oriented data model and communication protocol for Advanced Metering Infrastructures (AMI) and other Smart Metering systems [19]. IEC 62746-10-1 standardises the OpenADR 2.0b protocol (open automated demand response), consisting of data models and services related to demand response, pricing, and distributed energy resources [20]. Accordingly, in order to develop an ontology for energy DS, an alignment with these standards is primordial. Principle 5 (Align with existing standards). The methodology must ensure alignment to reference standards and data models.
In addition to the ontologies developed by the European projects presented in Section 2.2, other ontologies have been proposed for the energy sector. a reference for information exchange between energy actors [17]. These ontologies should be considered for reuse when defining a common ontology for the energy DS.
Principle 6 (Reuse existing ontologies). Focus on reusing concepts from existing ontologys. 9OMEGA-X - Orchestrating an interoperable sovereign federated Multi-vector Energy DS built on open standards and ready for GAia-X, 29 partners, 5 countries, 8 Me, GA 101069287 - https://omega-x.eu/
Also, like software artefacts, the development of an ontology is considered throughout its whole lifecycle.
Principle 7 (Support the entire original ontology engineering phase). encompassing ontological
requirements specification, implementation, publication, and maintenance [
Numerous methodologies have been introduced to assist in the development of ontologies. In this
section we review agile methodologies that are UC driven. The LOT methodology [
However, existing methodologies fail when it comes to standard integration, which is a highly important criteria to consider when designing ontologies for European DS. This involves defining criteria for ontology reuse, such as assessing their maturity, maintainability, and documentation comprehensiveness. Moreover, to enhance the discoverability and reusability of semantic artifacts, the methodology should advocate for the adoption of a common minimum metadata schema [21]. Given the complexity of large domains requiring interoperability between UC within a DS, and between DS, ontology engineers need additional assistance in defining their modules. This can be done by providing a fine grained description of UC in order to identify general patterns and create domain-specific and application-specific ontologies. This not only improves interoperability but also promotes reusability across diverse UC and DS. In response to these needs, we propose the AIME, which encompasses the principles outlined in section 2 and addresses gaps in existing methodologies, with a primary focus on enhancing the FAIRness of DS. The methodology is validated in OMEGA-X project in order to demonstrate the semantic interoperability of data sets developed within the OMEGA-X DS. The result will be promoted within the DS projects community and at standardization level (ISO/IEC JTC 1/SC 41). 10https://gitlab.com/acimov/acimov-methodology-template
This section describes the AIME methodology workflow depicted in Figure 1. A preliminary step consists in choosing reference standards and ontologies to be considered. As in state of the art methodologies, the entry point to knowledge acquisition is the creation of a backlog of UCs (detailed scope definition). To refine the acquisition process, step 3.3 of AIME focuses on modeling the data exchange captured by IMs. The design of ontology modules is then done in parallel by ontology engineers, in step3.4 and step 3.5. To ensure global consistency, a set of integration meetings gather development team members to align designed module (step 3.6), while a final step 3.7 releases the ontology. For illustration purposes, the section provides also examples of outcomes resulting from AIME application in the OMEGA-X project.
Actors: Domain Experts and Ontology Engineers; Inputs: Existing resources; Outcomes: Prioritized list of resources; Principles addressed: Principles 5, 6.
Description: This step consists of choosing reference resources that cover the domain to model. Reference models include domain ontologies, or standards of the domain.
In AIME, the selection of reference resources (ontologies and standards) is achieved based on the following criteria: • Resource overview: including creator, versioning, and publication date. • Resource documentation and references: Technical Specification Documentation, persistent URI, and related research papers. • Resource domain and usage: domain coverage, related UCs, addressed CQs, scope, and objectives [22]. • Resource modeling, reusability and availability: implementation language, available licence, content negotiation (if the user can request the resource in diferent formats such as RDF/XML, Turtle, N-Triples, etc), and registration in online catalogues. • Resource maturity and adoption: the maturity is assessed based on the Technology Readiness
Level (TRL) scale [23]. • Resource sustainability and maintainability level: varying from an individual person committed to the maintenance, to a professional organization such as a standardization body. Based on these criteria, domain experts and ontology engineers create a prioritised backlog of resources. The added value of considering existing standards is breaking down the access barrier to ontologies use and increasing their adoption. Indeed, in many contexts, domain experts are familiar with using standards in data modelling and exchanges. Moreover, it fosters the ability for knowledge from one domain to be relevant to another domain by doing feedback/gap analysis when applied to another UC.
In OMEGA-X project, step3.1 has been tooled with the creation of a template to support the selection of reference ontologies and standards based on the aforementioned criteria. Consequently, 3 reference energy domain ontologies (SEAS, SEDMOON, and INTERCONNECT), and 3 standards (IEC 62325-315, IEC 61850, IEC 62056) have been identified ( Section 2).
Actors: UC stakeholders and Ontology Engineers; Inputs: UC description; Outcomes: Prioritized backlog of UCs; Principles addressed: Principles 3, 4.
Description: The selection of UCs (and underlying data and services) to consider in the ontology design is achieved in collaboration with UC stakeholders (domain experts and software engineers) to investigate the level of maturity of the UC description. This analysis is performed to create a prioritized backlog of UCs to focus on, ensuring a business-driven approach. As a recommendation, a common template should be used to describe these UCs. The list of UCs can be updated during the ontology life cycle to handle possible extensions or changes of priority associated with a UC.
In OMEGA-X, UCs are grouped into Business UCs (BUC) and System UCs (SUC). The description of these UCs adheres to the methodology outlined in the IEC 62559-2 template including UC’s narrative, activity diagrams, technical details, actor descriptions (name, type, and description), step-by-step analysis, exchanged information, and requirements. Based on the maturity level of each UC, assessed by its responsible, the backlog of UCs is generated containing about 40 UCs (12 for local energy communities, 12 for flexibility, 10 for renewable energy and 6 for electromobility).
Actors: Domain Experts, Software Engineers and Ontology Engineers; Inputs: UCs; Outcomes: Prioritized backlog of IMs, Competency Questions (CQs); Principles addressed: Principles 2 , 4. Description: For each group of UCs, involved stakeholders are invited to workshops combining domain experts, software engineers and ontology engineers. The aim of these workshops is to define the IMs related to data exchanges occurring in the UCs. For each IM, CQs are formulated. Accordingly, a prioritised backlog of IMs is created. The identification of IMs helps to refine the granularity of knowledge acquired and enables the identification of terms shared within a specific domain and those common to multiple domains. The identification of domain specific/generic terms supports interoperability at diferent levels (intra-UC and inter-UCs).
In OMEGA-X, for each UC family, 8 UC ontology development (UC-OD) workshops have been organised between ontology engineers team, UC leader, UC participants (data providers and service providers). As a result, 60 IMs are defined. Thanks to IMs identification, a set of generic patterns have been identified (common terms and relationships), serving as a basis of the creation of common modules (cross-UCs).
Actors: Ontology Engineers and Domain Experts; Inputs: Selected resources, Selected UC, IMs and CQs; Outcomes: Selected conceptualisation; Principles addressed: Principles 2, 4, 5, 6, 7 . Description: Modelling each IM requires the creation of a conceptualisation. In priority, this task is achieved by reusing reference resources, to conform to Global interoperability requirements (with domain ontologies and standards).
Step 3.1: Terms extraction and lookup. The ontology engineers, with the cooperation of the domain experts, extract the Glossary of Terms (GoT) for each IM, and define each term based on existing well known resources. These definitions should be validated by domain experts who know exactly how these terms are used in the UCs. This step is repeated for each IM and a global GoT is created for the entire UC. After that, terms are classified based on general well known upper domain terms This classification can be based on foundational ontologies [ 24] and extended using the general concept from the reference model we are using. Note that the GoT is incremental ; it is updated each time a new term is identified. Terms that are not covered or not fully compatible with their definitions/uses are identified for the module’s formalisation.
In OMEGA-X, the GoT for each UC group is defined during UC-OD workshops where domain experts propose the exact definition of each term based on its usage in the project. The following sources have been considered for energy domain terms definitions: Electropedia [ 25], IEC 62325-325 standard [26] for energy market roles, IEC 61850 [18] for renewable UCs, OCPI [27] for electromobility UCs, etc.
Step 3.2: Conceptualisation attempt. For each IM, diferent conceptualizations are created using selected reference ontologies. The main idea is not to reinvent the wheel, however, try to model the IM using the already existing axioms. Moreover, terms that cannot be modelled should be indicated at the end of this step.
Step 3.3: Conceptualisation comparison. During ontology development meetings, ontology engineers compare the conceptualisation attempts to determine which one is convenient. The team evaluates the scope of each candidate conceptualisation based on diferent criteria such as: the extent of coverage of UC terms, and the conformity with UC definitions, and the global structure of the resource. When necessary, the chosen conceptualisation is extended to include classes from reference standards. Finally, the proposed conceptualisation is validated during a workshop with domain experts and software engineers. This proactive approach, aims to pinpoint gaps in current resources. Within the standards domain, identifying gaps based on UC requirements is crucial for reviewing existing versions and formulating recommendations to integrate in further versions.
Actors: Ontology Engineers; Inputs: Selected resources, Selected UC, IMs, CQs, and Selected Conceptualisation; Outcomes: Verified Ontology Module; Principles addressed: Principles 1, 7. Description: Given the selected conceptualisation, the ontology module is created in two steps:
Step 4.1: Formalisation. Given the integration of standards as reference resources in AIME, the formalisation step considers two types of formalisation. For ontological resources, the ontology engineers, to the best possible extent, reuse ontology classes and properties during the creation of the module. To respect best practices of ontology reuse, sub-classes are created if the reference ontology class does not fit the UC definition. On another hand, the formalisation of parts of module reusing standards requires the creation of a semantic version for the parts integrated in the conceptualisation. To distinguish provenance of concepts, the following annotations are used: • dcterms:description 11 to provide the term’s definition as it appears in source. • rdfs:seeAlso to link the concept to its standard definition.
• rdfs:isDefinedBy or dcterms:source to link the term to the resource where it is first defined.
Step 4.2: Verification. During the verification phase, engineers check the ontology module using validation tools such as OOPS! [28]. This enables the verification of the logical consistency, the naming conventions, the correctness of the class hierarchy, the completeness, and the annotations. Moreover, 11https://www.dublincore.org/specifications/dublin-core/dcmi-terms/. the ontology engineers use relevant UC knowledge graphs built from real data sets to verify CQs. It will help ontology users to understand the ontology and facilitates its use. Moreover, the ontology engineers check the consistency using reasoning engines. .
In OMEGA-X, at the first stage of the project, modules are created based on the outcomes of workshops. Common modules are defined to capture common knowledge of IMs, while specific UC modules represent UC specific knowledge. The formalisation is an iterative step that Real data sets were delivered by service providers and data providers to semantify the data based on the proposed modules. However, some common concepts were identified.
Actors: Ontology Engineers; Inputs: Modules; Outcomes: Integrated modular ontology; Principles addressed: Principles 1, 7.
Description: In complex modular ontologies, generalization patterns might emerge enabling to harmonize the global structure of the ontology and enable wider use tracks. Another challenge to consider in this phase is to track inconsistencies that might rely between diferent modules. The integration task leverages skills in terms of semantic alignments among modules, enabling for example to merge together concepts from diferent modules or to refine definitions associated to modules concepts if relevant. A critical aspect during the integration phase is the identification of modules interactions and the creation of semantic relationships strengthening the cohesion of the global ontology. To ensure intra and inter-UCs interoperability, it is recommended to create a general pattern for common concepts. Thus, integration meetings are organised to restructure modules. Some ontology modules can be considered as upper-level modules, common to all UCs since they contain general concepts that can define general patterns. Other modules are identified as domain level modules since they are shared by a group of use cases. Use case-oriented modules are defined as application ontology modules [ 29]. When required, an alignment module is created to ensure interoperability with domain ontologies and standards, strengthening also the reuse of datasets conforming to those resources. In OMEGA-X, during integration workshops, common concepts where identified as the energy production infrastructure, the data sets exchanged, the properties, the roles played by diferent stakeholders, and the data quality attributes. For example, in renewable UCs, the topology of the photovoltaic plants has been modeled, and then shared to other UCs such as flexibility where renewable energy is part of the process. The candidate conceptualisation chosen was the SEAS ontology, enriched with IEC 61850 standard for terms definitions and connections between infrastructure components. A second iteration of integration workshops enabled to create common simplified module for systems infrastructure that is reused in the electromobility for the charging infrastructure, and in the flexibility for the grid connections. The omega-X ontology includes 9 common modules and 4 UC modules (1 for each UC family).
Actors: Ontology Engineers; Inputs: The outcome of each methodology step (resource, UCs, interaction models, conceptualizations, CQs, ontology modules... ); Outcomes: Versioned ontological modules, Documentation, and Automation Scripts; Principles addressed: Principles 1, 2, 4, 7. Description: Gitlab/Github can be used to publish and maintain the ontology modules. It ensures versioning and issues tracking. Moreover, ontology modules can be generated by diferent ontology engineers, thus, namespaces and meta-data to be used should be set. For each module, a README file is added containing the module scope, the CQs with associated SPARQL queries, the diagram illustrating it, the glossary, reference standards if it exists, or any other useful document. An example of knowledge graph is added to each module. The use of a git-based repository provides the following features: • Agile Management: Use issue tracking and milestones for task management, along with boards for workflow visualization. • Team Collaboration and Documentation: Facilitate collaborative ontology updates through merge requests and maintain thorough documentation. • Version Control: Use branches and tags for releases to ensure access to stable versions. • Modular Development: Employ Git submodules to manage diferent parts of the ontology, allowing independent development and versioning of each module. • Open Collaboration: Make the repository accessible for public contributions and feedback, encouraging external involvement through forking and merge requests.
• Automation: Leverage CI/CD pipelines for automatic testing and deployment.
Moreover, the ontology should have a globally unique, persistent and resolvable identifier [ 30]. To be FAIR-compliant, the following metadata are proposed [30]: • Resolvable and persistent identifier: owl:ontologyIRI, vann:preferredNamespacePrefix, vann:preferredNamespaceUri . • Description: dcterms:description, rdfs:label. • Authorship and Attribution: dcterms:rights, dcterms:license,dcterms:publisher, dcterms:contributor and dcterms:creator. • Maintenance and versionning: owl:versionInfo, owl:priorVersion, dcterms:created, dcterms:published, dcterms:modified.
• Intellectual Property and Licensing Terms: dcterms:license, dcterms:rights Moreover, FOOPS! [31] web service can be used to evaluate FAIR aspects of the ontology module. The OMEGA-X modular ontology has been developed and published in a Gitlab repository where ontology engineers and UC participants are members. For each module, a dev branch is created by an ontology engineer where the diagram, the ontology file (turtle), the README file, the dataset, and the SPARQL queries are added. Updates of the module is released after integration meetings. The issues tracker of Gitlab was used to manage task allocation, milestone definition for release, and include feedback from stakeholders. Each module has been scored with FOOPS! tool. To cope with FAIRness requirements, the ontology and the methodology materials are published using a persistant URI (w3ID) 12.This enables to provide both general documentation and templates for the methodology steps, and the resulting ontology with its application domains.
In this paper, we present AIME, an agile UC-centric ontology development methodology explicitly tailored to the complex challenges encountered in Data Space projects. In alignment with the European Union’s initiative, AIME strongly emphasises supporting data space adherence to FAIR data principles, ensuring that data and services exchanged are findable, accessible, interoperable, and reusable. To support interoperability inside and beyond data space, the first step of resource selection provides criteria for ontology and standard selection, conducting gap analyses to ensure quality resource reuse. Considering standards and producing guidelines for their homogenous reuse during conceptualisation is another added value of AIME. AIME ensures that resulting ontologies efectively capture domain knowledge while promoting interoperability and compatibility with existing standards. Recognising the inherent complexity, diversity and dynamicity of DS, AIME proposes a detailed approach for an in-depth knowledge acquisition process by the use of Interaction Models, capturing dynamic exchanges of data and services, enriching metadata creation for optimal findability and reuse. Through its iterative approach, AIME enables communication and collaboration among domain experts, data/service providers, and ontology engineers at each step of the ontology development lifecycle. It facilitates continuously refining knowledge acquisition and identifying common patterns for the eficient development of modular ontologies. A set of metadata recommendations is also provided to help identify the provenance of modules (or parts of modules), enhance data comprehension and enable reusability and accessibility. Finally, AIME facilitates creating, publishing, and maintaining ontology modules using GitLab/GitHub tools. AIME has been developed and applied in the context of the OMEGA-X project, which focuses on building an energy DS, where AIME has demonstrated its eficacy in guiding the development of modular ontologies that capture the complex relationships and interactions within the energy domain and the data space setting. The resulting modular ontology is under demonstration in pilot UC, and stakeholders feedback is continuously integrated in the ontology development. Further eforts are underway to explore the application of this methodology in sister projects such as ENERSHARE and Eddie projects. The methodology can serve in finding a common use case description between diferent sister projects.
As DS initiatives continue to evolve and expand across sectors such as health, energy, and mobility, AIME holds potential for testing it in these DS and ofers a robust methodology for developing ontologies that lay the foundation for the seamless exchange and reuse of data within European DS.
This work is funded by the European Union’s Horizon Europe innovation action program under grant agreement no [101069287] (OMEGA-X). https://omega-x.eu/. seas/seas-1.1, version: 1.1, Latest version: https://w3id.org/seas/, Previous version: https://w3id. org/seas/seas-1.0, Issued: 2017-08-29. [13] L. Daniele, C. Bouter, G. Jung, K. Helmholt, R. van der Weert, V. de Boer, C. M. Pereira, D2.3
Interoperable and Secure Standards and Ontologies, Deliverable D2.3, Interconnect Project, 2023. [14] S. Ben Abbes, L. Temal, PLATOON Common Data Models for Energy, Deliverable D2.3, PLATOON
Project, 2023. [15] A. S. Abdelghany, N. R. Darwish, H. A. Hefni, An agile methodology for ontology development,
International Journal of Intelligent Engineering and Systems 12 (2019) 170–181. [16] European Commission, Bridge WG Data Management Use Case Repository Report 2020-2021, Technical Report, European Commission, 2021. URL: https://energy.ec.europa.eu/system/files/ 2021-06/bridge_wg_data_management_use_case_repository_report_2020-2021_0.pdf. [17] IEC, Energy management system application program interface (EMS-API) - Part 301: Common information model (CIM) base, International Standard IEC 61970-301:2020, 2020. [18] IEC, Communication networks and systems for power utility automation, International Standard
IEC 61850:2013, 2013. [19] J. A. Cortés, J. M. Idiago, Smart metering systems based on power line communications, Smart
Grids and Their Communication Systems (2019) 121–170. [20] IEC, Systems interface between customer energy management system and the power management system-Part 10-1: Open Automated Demand Response (OpenADR 2.0 b Profile Specification), International Standard IEC 62746-10:2018, 2018. [21] D. Garijo, S. Jupp, E. Willighagen, J. Graybeal, M. Dumontier, C. Goble, Coming to terms with FAIR: Principles for the development of scientific ontologies, in: Knowledge Engineering and Knowledge Management - 23rd International Conference, EKAW 2020, Bolzano, Italy, September 14-18, 2020, Proceedings, 2020, pp. 76–91. doi:10.1007/978-3-030-62466-8\_6. [22] D. Wiśniewski, J. Potoniec, A. Ławrynowicz, C. M. Keet, Analysis of ontology competency questions and their formalizations in SPARQL-OWL, Journal of Web Semantics 59 (2019) 100534. [23] Horizon Europe, Guiding notes to use the TRL self-assessment tool (2020). [24] B. Smith, W. Ceusters, Functions in basic formal ontology (2015). URL: https://ontology.bufalo.
edu/smith/articles/Functions-in-BFO.pdf, accessed: 2024-06-19. [25] IEC, Electropedia, 2007. URL: https://www.electropedia.org/, accessed: October 1, 2024. [26] International Electrotechnical Commission, IEC 62325-451-3:2019 ED1.1, Technical Report ED1.1, International Electrotechnical Commission, 2019. URL: https://webstore.iec.ch/preview/info_ iec62325-451-3%7Bed1.1%7Db.pdf. [27] OCPI Association, Open Charge Point Interface (OCPI) Specification Version 2.2, Technical Report,
OCPI Association, 2020. URL: https://evroaming.org/app/uploads/2020/06/OCPI-2.2-d2.pdf. [28] M. Poveda-Villalón, M. C. Suárez-Figueroa, A. Gómez-Pérez, Validating ontologies with oops!, in: Knowledge Engineering and Knowledge Management: 18th International Conference, EKAW 2012, Galway City, Ireland, October 8-12, 2012. Proceedings 18, Springer, 2012, pp. 267–281. [29] L. Elmhadhbi, M.-H. Karray, B. Archimède, Toward the use of upper-level ontologies for semantically interoperable systems: An emergency management use case, in: Enterprise Interoperability VIII: Smart Services and Business Impact of Enterprise Interoperability, Springer, 2019, pp. 131–140. [30] E. Amdouni, S. Bouazzouni, C. Jonquet, O’faire makes you an ofer: metadata-based automatic fairness assessment for ontologies and semantic resources, International Journal of Metadata, Semantics and Ontologies 16 (2022) 16–46. [31] D. Garijo, O. Corcho, M. Poveda-Villalón, Foops!: An ontology pitfall scanner for the fair principles., in: ISWC (Posters/Demos/Industry), 2021.