# Toward Agile Interaction Model based ontology development Methodology (AIME) for FAIR European data spaces

Lina Nachabe, Fatma-Zohra Hannou, Maxime Lefrançois, Marie Jubault

► To cite this version:

Lina Nachabe, Fatma-Zohra Hannou, Maxime Lefrançois, Marie Jubault. Toward Agile Interaction Model based ontology development Methodology (AIME) for FAIR European data spaces. FAIR Principles for Ontologies and Medatata in Knowledge Management (FOAM), Jul 2024, Enschede, Netherlands. [hal-04765023](https://hal.science/hal-04765023v1)

HAL Id: hal-04765023

https://hal.science/hal-04765023v1

Submitted on 12 Nov 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Toward Agile Interaction Model based ontology development Methodology (AIME) for FAIR European data spaces

Lina Nachabe<fnref n="1" />,*,†, Fatma-Zohra Hannou<fnref n="2" />,†, Maxime Lefrançois<fnref n="1" />,† and Marie Jubault<fnref n="2" />

## Abstract

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 different 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.

## Keywords

Data space, FAIR principles, Ontology engineering methodology, European standards, Agile development, Modular ontologies

## 1. Introduction

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 offer 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. Ontology-based 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 [1].

<figure><img src="image_2.png" /></figure>

<figure><img src="image_3.png" /></figure>

<figure><img src="image_4.png" /></figure>

<footnote n="1">¹Mines Saint-Étienne, Univ. Clermont Auvergne, INP Clermont Auvergne, CNRS, UMR 6158 LIMOS, F-42023, Saint-Étienne, France</footnote>

<footnote n="2">²EDF R&D, Saclay, France</footnote>

<footnote>FOAM 2024: FAIR principles for Ontologies and Metadata in Knowledge Management, July 15–19, 2024, Enschede, Netherlands
* Corresponding author.</footnote>

<footnote>† These authors contributed equally.</footnote>

<footnote>lina.nachabe@emse.fr (L. Nachabe); fatma-zohra.hannou@edf.fr (F. Hannou); maxime.lefrancois@emse.fr (M. Lefrançois); marie.jubault@edf.fr (M. Jubault)</footnote>

<footnote>0000-0003-3924-3336 (L. Nachabe); 0000-0003-4747-1232 (F. Hannou); 0000-0001-9814-8991 (M. Lefrançois); 0000-0001-8264-9628 (M. Jubault)</footnote>

<footnote>© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).</footnote>
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<fnref n="1" />, using DCAT<fnref n="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) [2] and (ACIMOV) [3], to integrate domain standards and refine knowledge acquisition process driven by interaction models (IM). An IM describes the data exchanged between two actors to reach a specific goal and is usually expressed using sequence diagrams. This approach ensures that the resulting ontology captures multiple levels of domain interoperability and increases the findability and reuse of datasets and services. The development of the AIME methodology has been achieved within the OMEGA-X European project, which aims to create a DS for the energy domain. AIME application enabled the creation of a modular ontology for the European Energy DS, by addressing specific requirements for business-driven approaches, linkage to diverse UC, and continual adaptation to new concepts and standards.

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.

# 2. Background and Principles

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.

## 2.1. Semantic interoperability in data spaces

A DS is an ecosystem structured around agreed-upon elements, facilitating the effective and trusted sharing of data among participants to generate value [4].

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 [5]. The recently enforced European data act defines DS as: “purpose or sector specific or cross-sectoral interoperable frameworks for

<footnote n="1">¹https://w3id.org/gaia-x</footnote>

<footnote n="2">²https://www.w3.org/TR/vocab-dcat-3/</footnote>
common standards and practices to share or jointly process data for, inter alia, the development of new products and services, scientific research or civil society initiatives.” [6, Whereas (103)]. For example, the European energy DS fosters transparency and collaboration among energy stakeholders [7]. The variety of domains and sub-domains at stake in the Energy sector, and the cross-sectorial ambition of the common European DS, imposes the following principle on the development of the OMEGA-X common ontology:

**Principle 1 (Target modularity).** The ontology engineering methodology should target the development of a modular ontology, consisting of top-level modules, a set of loosely coupled modules that each focus on an aspect of the domain, and modules specific to UC applications [8].

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 [9]. Moreover, they should be shared in a machine readable and interpretable language to be processed by different parties. Consequently, the development of a common ontology for the EDS imposes the following principle:

**Principle 2 (Target FAIR).** The methodology should target compliance of the ontology to the FAIR principles. That is, the ontology has to be 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.

## 2.2. European projects contributing to the European energy data spaces

Several projects explored data interoperability in the energy sector [10]. This section shortly describes some of these projects, focusing on European projects that tackle semantic interoperability. The precursing Eureka ITEA SEAS project<fnref n="3" /> investigated real time data-exchange among electrical production and consumption systems, and proposed 120 UC classified in six main categories along with the 30-module ontology SEAS<fnref n="4" /> for the energy domain [11, 12].

Large-scale project H2020 INTERCONNECT<fnref n="5" /> 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-11-2019 "Big data solutions for energy" funded four projects, including PLATOON<fnref n="6" /> [14], which contributed with semantic web technologies and the SEDMOON (ontologys Of Energy) ontologies<fnref n="7" />. 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<fnref n="8" /> includes 7 pilots in 7 countries including local energy communities electromobility, flexibility and renewables focusing

<footnote n="3">³SEAS - Smart Energy-Aware Systems, 35 partners, 7 countries, https://itea4.org/project/seas.html</footnote>

<footnote n="4">⁴https://w3id.org/seas/</footnote>

<footnote n="5">⁵INTERCONNECT - Interoperable Solutions Connecting Smart Homes, Buildings and Grids, 50 partners, 11 countries, 30 M€, GA 857237 - https://interconnectproject.eu/</footnote>

<footnote n="6">⁶PLATOON - Digital PLAtform and analytic TOOIs for eNergy, 20 partners, 9 countries, 10 M€, GA 872592 - https://platoon-project.eu/</footnote>

<footnote n="7">⁷https://w3id.org/platoon/</footnote>

<footnote n="8">⁸ENERSHARE - Enershare facilitates the energy sovereign and trusted data exchange, 28 partners, 12 countries, 10M € - GA 101069831 - https://enershare.eu/</footnote>
on wind energy. OMEGA-X<fnref n="9" /> 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 coordination between these different 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.

## 2.3. Stakeholders, standards and ontologies for the energy domain

The traditional energy grid involves different 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 efficiency 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** (DLMS (Device Language Message Specification)-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 ontologies.

Also, like software artefacts, the development of an ontology is considered throughout its whole lifecycle.

<footnote n="9">⁹OMEGA-X - Orchestrating an interoperable sovereign federated Multi-vector Energy DS built on open standards and ready for GAia-X, 29 partners, 5 countries, 8 M€, GA 101069287 - https://omega-x.eu/</footnote>
**Principle 7** (Support the entire original ontology engineering phase). encompassing ontological
requirements specification, implementation, publication, and maintenance [2].

**2.4. Related Work on ontology Engineering Methodologies**

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 [2] is used to develop
ontologies and vocabularies in industrial projects. It is an agile methodology that takes into consideration
the intervention of ontology developers, domain experts and ontology users. The first step is to define
ontology requirements specification relying on UC specification and data exchange identification. Then,
the purpose and scope of the ontology, the Competency Questions (CQs) (questions written in formalized
natural language and permit to understand the goal of the ontology), and the functional ontological
requirements are formalised in an Ontology Requirements Specification Document (ORSD). The second
step is the ontology implementation which is done iteratively. It includes the conceptualisation using
UML based notation, ontology encoding and ontology reuse. The ontology is then evaluated in two steps:
validation against the meaning it is intended to model, and verification using CQs. Thirdly, the ontology
is published and documented. Finally, the ontology is maintained during its life cycle. LOT proposes
git-based approach for managing the ontology development process that ensures versioning. However,
more investigation should be done on modularization approach and the criteria for ontology reuse.
LOT has been employed in the context of the Horizon Europe INTERCONNECT project to create the
ontology modules for interoperable solutions connecting smart homes, buildings and grids. PLATOON
adopted a bottom-up and UC centric methodology derived from LOT. In the PLATOON methodology,
ontology requirements are set from the UC repository where UC are described using the IEC 62559
template. Relevant terms are identified and extracted along with examining lists of CQs. Modules
are created and diagrams integration are done by ontology experts to harmonize the ontology to be
published. The PLATOON methodology is being reused by the ENERSHARE project. The methodology
lacks of a maintenance process. The ACIMOV methodology [3] is an agile methodology that aims to
define homogeneous and predictable structure of modules, to use collaborative software platform with
code versioning, and to set regular meetings between all parties and between ontology engineers. After
collecting the requirements, review meetings are set and CQs are defined. The ontology engineers
will choose reference ontologies, manage a backlog of modules, develop and tests modules. Authors
suggest to use Gitlab or Github during the development life cycle, and provide repository templates
and scripts for continuous integration and deployment of the ontology.<fnref n="10" /> Table 1 depicts how our
methodology principles are covered by each of the previously mentioned methodologies. Only ACIMOV
incorporates agility principles and collaborative software platform with code versioning explicitly. In
addition, it showcases that 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).

<footnote n="10">¹⁰https://gitlab.com/acimov/acimov-methodology-template</footnote>
<table><caption>**Table 1**
Methodology Comparison based on our Methodology principles</caption><thead><tr><th rowspan="2">Methodology Principle</th><th colspan="4">Methodology</th></tr><tr><th>LOT</th><th>PLATOON</th><th>ACIMOV</th><th>AIME</th></tr></thead><tbody><tr><td>P1. Criteria for modularity</td><td>yes</td><td>yes</td><td>yes</td><td>yes</td></tr><tr><td>P2. Metadata enabling FAIR ontologies</td><td>partially</td><td>no</td><td>no</td><td>yes</td></tr><tr><td>P3. Be UC centric</td><td>partially</td><td>partially</td><td>partially</td><td>yes</td></tr><tr><td>P4. Be agile</td><td>no</td><td>no</td><td>yes</td><td>yes</td></tr><tr><td>P5. Align with existing standards</td><td>no</td><td>no</td><td>no</td><td>yes</td></tr><tr><td>P6. Criteria for reusing reference ontologies</td><td>no</td><td>partially</td><td>partially</td><td>yes</td></tr><tr><td>7. Support the original ontology engineering phase</td><td>yes</td><td>lack for ontology maintenance</td><td>yes</td><td>yes</td></tr></tbody></table>

### 3. Description of the AIME Methodology

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 step 3.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.

<figure><img src="image_5.png" /><figcaption>**Figure 1:** Overview of the AIME methodology workflow</figcaption></figure>
**3.1. Step 0: Select ontological and non ontological resources**

**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** (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, 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, 4 reference energy domain ontologies (SEAS, SEDMOON, SARGON, and INTERCONNECT), and 3 standards (IEC 62325-315, IEC 61850, IEC 62056) have been identified (Section 2).

**3.2. Step 1: Create a backlog of UCs**

**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).

**3.3. Step 2: Create a backlog of Interaction Models**

**Actors:** Domain Experts, Software Engineers and Ontology Engineers; **Inputs:** UCs; **Outcomes:** Prioritized backlog of IMs, Competency Questions (CQs); **Principles addressed:** Principles 4, 2

**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 different 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).

**3.4. Step 3: Model the IMs with selected resources**

**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, different 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 different 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.

**3.5. Step 4: Create ontology module**

**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<fnref n="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, 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.

**3.6. Step 5: Integrate ontology modules**

**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 different modules. The integration task leverages skills in terms of semantic alignments among modules, enabling for example to merge together concepts from different 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 different 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 7 common modules and 4 UC modules (1 for each UC family).

<footnote n="11">¹¹https://www.dublincore.org/specifications/dublin-core/dcmi-terms/.</footnote>
## 3.7. Step 6: Publish and maintain the ontology

**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 different 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 by using issue tracking and milestones for task management, along with boards for workflow visualization; Team Collaboration and Documentation to facilitate collaborative ontology updates through merge requests; Version Control using branches and tags for releases to ensure access to stable versions; Open Collaboration by making the repository accessible for public contributions and feedback; Automation by leveraging CI/CD pipelines for automatic testing and deployment. To be FAIR-compliant, the following metadata are proposed [30]: **Resolvable and persistent identifier** (owl:ontologyIRI, vann:preferredNamespacePrefix, vann:preferredNamespaceUri); **Description** (dcterms:ddescription, rdfs:label); **Authorship and Attribution** (dcterms:rights, dcterms:license, dcterms:publisher, dcterms:contributor and dcterms:creator); **Maintenance and versioning** (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 persistent URI (w3ID)<fnref n="12" />. This enables to provide both general documentation and templates for the methodology steps, and the resulting ontology with its application domains.

## 4. Conclusion and Future works

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 dataspace, 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 effectively 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 efficient development of mod-

<footnote n="12">¹²https://w3id.org/omega-x/</footnote>
ular 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 efficacy 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 efforts 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 different
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 offers a robust methodology for developing ontologies that lay the foundation for the seamless exchange and reuse of data within European DS.

Acknowledgments

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/.

References

[1] GAIA-X European Association for Data and Cloud, Gaia-x - Architecture Document - 22.04 Release, Technical Report, 2022.

[2] M. Poveda-Villalón, A. Fernández-Izquierdo, M. Fernández-López, R. García-Castro, LOT: An industrial oriented ontology engineering framework, Engineering Applications of Artificial Intelligence 111 (2022) 104755.

[3] F.-Z. Hannou, V. Charpenay, M. Lefrançois, C. Roussey, A. Zimmermann, F. Gandon, The ACIMOV methodology: Agile and continuous integration for modular ontologies and vocabularies, in: MK 2023-2nd Workshop on Modular Knowledge associated with FOIS 2023-the 13th International Conference on Formal Ontology in Information Systems, 2023.

[4] S. Scerri, T. Tuikka, I. L. de Vallejo, E. Curry, Common european data spaces: Challenges and opportunities, Data Spaces: Design, Deployment and Future Directions (2022) 337–357.

[5] European Commission, Data Spaces Panel Report, https://data.europa.eu/sites/default/files/report/Data_Spaces_Panel_Report_EN.pdf, 2020. Accessed: March 8, 2024.

[6] European parliament and council of the european union, Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data and amending Regulation (EU) 2017/2394 and Directive (EU) 2020/1828 (Data Act), 2024. URL: https://eur-lex.europa.eu/eli/reg/2023/2854, document 32023R2854.

[7] A. Dognini, C. Challagonda, E. Maqueda Moro, K. Helmholt, H. Madsen, L. Daniele, L. Schmitt, O. Genest, R. Riemenschneider, R. Böhm, R. Ebrahimy, L. Temal, P. Calvez, S. Ben Abbes, Data spaces for energy, home and mobility, 2022. doi:10.5281/zenodo.7193318.

[8] M. Bauer, H. Baqa, E. G. Market, R. García-Castro, M. Girod-Genet, C. El Kaed, J. Lee, M. Lefrançois, Towards semantic interoperability standards based on ontologies, AIOTI White paper (2019).

[9] G. Guizzardi, Ontology, ontologies and the “i” of fair, Data Intelligence 2 (2020) 181–191.

[10] V. Reif, T. I. Strasser, J. Jimeno, M. Farre, O. Genest, A. Gyrard, M. McGranaghan, G. Lipari, J. Schütz, M. Uslar, et al., Towards an interoperability roadmap for the energy transition, e & i Elektrotechnik und Informationstechnik 140 (2023) 478–487.

[11] M. Lefrançois, J. Kalaoja, T. Ghariani, A. Zimmermann, The SEAS knowledge model, Deliverable D2.2, ITEA2 12004 Smart Energy Aware Systems, 2016.

[12] Maxime Lefrançois, A. Zimmermann, E. Siira, T. Ghariani, M. Girod-Genet, G. Santos, F. Silva,
L. Temal, B. Teixeira, H. Järvinen, Jarmo Kalaoja, SEAS Ontology, 2017. URL: https://w3id.org/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.buffalo.edu/smith/articles/Functions-in-BFO.pdf, accessed: 2024-06-19.

[25] IEC, Electropedia, 2007. URL: https://www.electropedia.org/, accessed: July 5, 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 offer: 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.