Introduction
The interoperability problem in buildings stems from the challenge of integrating the diverse systems, tools, and data formats used in modern building management. Systems such as HVAC, lighting, security, and energy management often operate using different communication protocols and software platforms, making it difficult to ensure seamless data-sharing and coordination. One common issue is the lack of standardized data formats across systems, which leads to inefficient data handling and the need for manual data reentry1. This problem becomes more pronounced as more buildings adopt smart technology solutions that rely on real-time data exchange and automation to optimize operations. Without interoperability, the potential benefits of energy efficiency, safety, and operational performance often diminish2.
The interoperability challenge is particularly evident in building information modeling (BIM). BIM systems are essential for designing, constructing, and managing buildings; however, various software tools used by different stakeholders—architects, engineers, and contractors—are not always compatible. The Industry Foundation Classes (IFC) standard3, developed by buildingSMART, aims to address this by creating a common data format; however, limitations still persist in practice. For instance, although IFC helps with data exchange, it does not fully solve issues related to semantic interoperability4, where different systems interpret data inconsistently. This can result in errors and inefficiencies in the design and construction phases. Moreover, integrating BIM with other tools, such as energy analysis or facility management software, often requires additional customization, which adds complexity and cost to building projects5.
The interoperability issue in buildings also affects the implementation of demand response programs, which are critical for managing energy use, particularly in smart grids. Demand response involves adjusting the energy consumption in buildings in response to signals from the grid, often incentivizing users to reduce usage during peak demand periods6. For an effective demand response, building systems, such as HVAC, lighting, and appliances, must communicate seamlessly with the grid, often requiring real-time data exchange and automated control adjustments. However, the lack of interoperability between different building management systems (BMS) and grid technologies hinders this integration. In other words, this problem arises primarily from the fragmentation of standards, protocols, and technologies used in buildings. Systems such as Building Energy Management Systems (BEMS) and Smart Home automation often operate on different, sometimes proprietary, protocols, making it difficult for them to communicate efficiently with the grid7. This gap in interoperability limits the ability of buildings to respond efficiently to grid signals, which is crucial for optimizing energy use, reducing costs, and improving the overall grid stability.
Nowadays, buildings are becoming more complex structures, incorporating a range of technologies such as lighting, HVAC, and other systems, and the need for interoperability is critical8. This ensures that these different components can effectively communicate, share data, and function together seamlessly to enhance the energy efficiency and overall building performance. Without interoperability, systems would operate in isolation, missing opportunities for optimization, and dynamic responses to changing conditions, such as occupancy or weather.
Interoperability is also essential for achieving sustainability and energy efficiency targets9. When building systems can exchange information in real time, they can automatically adjust energy consumption based on current needs, reducing waste and environmental impact. This dynamic control over energy-intensive devices helps create smart, energy-efficient buildings capable of evolving alongside technological advancements and environmental considerations9.
DR has become a key element in the modern energy sector, particularly in the EU markets. Efforts have been made to standardize DR data models, as demonstrated by some authors10 who developed tools that allow DR systems to distribute their components in the cloud while ensuring secure and private data exchange. These tools also feature a semantic interoperability layer that enables the translation of data into standardized formats during the exchange process. Other researchers11 have focused on refining the formal semantics of DR components, such as defining what constitutes an object (its "type") and detailing its attributes, with the aim of encouraging wider adoption and reducing the associated soft costs.
Various studies have focused on developing and testing interoperable DR systems using methodologies such as the Smart Grid Architecture Model and interoperability-by-design frameworks12,13. These approaches involve defining system architectures, selecting appropriate standards and protocols, and conducting rigorous testing to ensure seamless integration of diverse components13,14. Experimental setups, such as home energy management systems and remote load control, have demonstrated the feasibility of explicit DR schemes12,14. Semantic and canonical data models have been proposed to address the data heterogeneity and integration challenges15. These efforts aim to enhance the reliability and efficiency of DR programs, enabling better management of peak demand and the integration of renewable energy sources in residential buildings and districts.
The remainder of this study is structured as follows. First, the interoperability levels will be defined, how the DEDALUS project takes these levels into account, and the existing ontologies analysis. Second, the DEDALUS base ontology will be described, based on the DR requirements, and including extensions to achieve interoperability. Next, the interoperability enablers are explained, as well as how the ontology is practically integrated in real applications and services within a set of buildings. Finally, conclusions and future research directions are presented.
Methods
In contrast to previous research, this study proposes the standardization of a methodology for assuring semantic interoperability in demand response programs. While previous results show a lack of full interoperability, the use of common standards would help the integration of various building systems. In this line, this manuscript summarizes how the current standard data models fit into the demand response paradigm and analyzes the required extensions over them so that interoperability can be applied. The work was conducted in the context of the EU project DEDALUS16, which aims to develop a participatory DR ecosystem with the following objectives: (a) to facilitate and scale up the large-scale participation of residential energy consumers in DR and (b) to adapt to various mono-carrier (e.g., electricity, heat) or multi-carrier synergetic scenarios (e.g., electricity, heat, and natural gas) at both the building and district levels.
To address the outlined interoperability challenges, this study adopts a multi-layered methodological approach, developed within the framework of the DEDALUS project. The approach focuses on foundational, structural, and semantic interoperability levels to ensure seamless integration of building systems with Demand Response (DR) programs.
At the foundational level, the Demand Response Control Ontology (dCO) serves as the core semantic model, specifically tailored to energy management and DR requirements. The ontology is designed to address gaps identified in previous research, integrating essential concepts and facilitating consistent data interpretation across systems. By extending dCO with entities relevant to DR scenarios, the study addresses limitations in current ontology frameworks10,11.
The structural level emphasizes the integration of existing ontologies such as SAREF (Smart Appliances REFerence ontology), OpenADR (Open Automated Demand Response), and Brick schema. These ontologies provide a standardized representation of data, reducing development complexity and ensuring interoperability across different building systems. The use of these established standards supports the consistent exchange of data between systems, which is essential for optimizing energy performance and enhancing grid responsiveness.
At the semantic level, the project utilizes the FIWARE NGSI-LD (Next Generation Service Interface-Linked Data) standard for context information management, ensuring real-time data exchange and system compatibility. This setup facilitates automated responses to grid signals and allows for dynamic adjustments in energy consumption, essential for effective DR implementation15. The adoption of open-source frameworks and machine-readable formats, such as JSON-LD, ensures that the data exchange process is efficient and adaptable to evolving technological needs.
The methodology includes experimental validation through case studies and real-world setups, simulating building environments to test energy management and DR strategies. Key performance indicators, such as energy efficiency, response time, and system reliability, are measured to evaluate the effectiveness of the proposed framework16. This comprehensive approach seeks to advance interoperability standards and contribute to sustainable and energy-efficient building management.
Interoperability levels in demand response
As previously mentioned, interoperability in the building energy management sector is a crucial concept that addresses seamless integration and communication between diverse systems and devices within a building's energy infrastructure. Figure 1 conceptualizes the interoperability problem, where a set of sensor networks communicates with high-level services. As observed, different languages are used (English, Spanish, German, and Chinese), while data structures differ (i.e., using brackets, equal symbols, braces, etc.), and/or semantics are not common (i.e., limiting the capability of self-understanding the information). This means that there is no standardized method of communication.
Figure 1. Interoperability problem definition about the interaction between sensor networks and services (Source: Own work).
Translating this simple example into the building, standard communication protocols, and interfaces from building monitoring systems (BMS) are key. However, there is no consensus on how manufacturers cohesively interact with each other. For instance, various protocols exist, such as the Building Automation and Control networks (BACnet), Modbus, or Message Queuing Telemetry Transport (MQTT), among others, which provide different ways to communicate (same as the example illustrated in Figure 1). Only by adhering to one of these standards can building owners and operators select best-of-breed solutions from different vendors without worrying about compatibility issues, thereby fostering a more competitive and innovative marketplace17. Nevertheless, this a limitation in demand response activities where multiple vendors and devices take place at the same time.
Definition within DEDALUS project
Based on the interoperability problem defined above, DEDALUS determines three levels of interoperability. Figure 2 depicts these according to the definitions given by the authors in 18.
Foundational interoperability: Interaction between two or more information systems with the aim of exchanging data. It can be divided into two levels.
• Northbound interoperability allows interaction between data repositories (data lake) and applications (or, in other words, high-level services).
• Southbound interoperability in charge of gathering data from data sources or devices in different ways or protocols via (Internet of Things).
Structural interoperability to set up a common or standard structure of format for data exchange using uniform flows and meaning of data, keeping them preserved and unaltered. This is a way to define data syntax.
Semantic interoperability, which, thanks to the use of data models, provides the ability to understand data between two or more information systems. Benefiting from the structures and codification of data, it generates vocabularies so that message recipients can interpret the data in an intended way.
Figure 2. Levels of interoperability: Foundational, semantic and structural (Source: Own work).
In this study, semantic interoperability is the main objective, where a DR data model is established based on standard ontologies. The advantage is that it enables seamless data collection procedures and interpretation.
Ontologies used in demand response
One of the fundamental principles in ontology development is the reuse of existing ontologies to the greatest extent possible, ensuring consistency and interoperability across systems, while reducing redundant efforts. Accordingly, a preliminary state-or-the-art19 was conducted to identify existing ontologies that could serve as a foundation for the creation of the DEDALUS ontology. This initial exploration aimed to leverage established structures and concepts, enabling us to extend them based on specific data requirements provided by service developers and pilot projects. These tailored extensions ensure that the new ontology effectively supports the diverse needs of stakeholders, while building upon a solid and reusable framework.
For state-of-the-art analysis, the following ontologies were selected:
SAREF (Smart Appliances REFerence ontology)20: SAREF is an ontology designed to enable interoperability between smart appliances in the Internet of Things (IoT) ecosystem, facilitating the exchange of energy and other related services. The concepts of SAREF models are related to demand response, particularly through its extensions such as SAREF4ENER, which provides the vocabulary for representing energy-related functionalities, including demand-response interactions. Available at: https://saref.etsi.org/.
OpenADR (Open Automated Demand Response)21: OpenADR is an open standard for automated demand response, enabling devices to receive and respond to demand response signals in a standardized manner. It focuses specifically on demand-response concepts, providing a robust framework for managing demand-response events in energy systems. Available at: http://www.openadr.org/.
Brick22: A brick is a uniform metadata schema for buildings that enables interoperable descriptions of physical, logical, and virtual assets in buildings. While Brick is primarily focused on describing building systems (HVAC, lighting, etc.), it can support demand-response interactions indirectly by integrating with energy management systems. Available at: https://brickschema.org/.
dCO ontology23: The dCO ontology is designed to describe devices, measurements, and services in the context of smart buildings and energy management. Although dCO provides an extensive model for energy consumption, devices, and services, it does not explicitly focus on demand-response concepts. Available at: https://w3id.org/dco.
BIGG Ontology24: This ontology was developed within the BIGG project to support data models for large-scale buildings, focusing on energy efficiency and management. Like dCO, BIGG ontology models’ energy-related aspects do not explicitly cover demand-response concepts. Available at: http://bigg-project.eu/ontology.
Each of these ontologies brings valuable concepts and models, some of which explicitly address demand-response functionality (e.g., SAREF and OpenADR), whereas others focus more broadly on energy management and building systems.
After careful consideration, the dCO ontology was selected as the base ontology for the project19. This decision was made because the dCO aligns more closely with the project requirements. Its flexibility and comprehensive structure allowed for the necessary extensions to meet the specific needs of the pilots and the data provided by service developers, making it the best fit for the foundational layer of the ontology.
DEDALUS ontology
Analysis of requirements
Defining requirements in the context of interoperability for demand response is crucial to ensure seamless communication and coordination between various systems, devices, and stakeholders. Clearly established requirements set the foundation for compatibility, ensuring that systems can exchange information accurately and in real-time. This not only enhances the responsiveness of the demand response program but also increases the reliability and scalability of energy solutions. Well-defined requirements help prevent technical conflicts, reduce integration costs, and promote innovation by creating a standardized framework for diverse technologies to collaborate. In turn, this boosts participation in demand response programs, optimizes energy usage, and contributes to a more resilient, sustainable grid.
This analysis is part of the methodology applied in this research, as shown in Figure 319. It consists of four steps: 1) state of the art in terms of existing ontologies within the DR domain, as it was included in the previous chapter; 2) analysis, where the features from the SotA ontologies are extracted with the main pros and cons that are mapped into the requirements to determine their capability to host data effectively; 3) selection of the most suitable ontology (next section) after the matching process in step 2; and 4) extension so that features not included in the base ontology could represent entities that are required within the DM programs.
Figure 3. Methodological approach followed in the standardized ontology development (Source: Own work).
As explained above, the analysis of the requirements is part of the second step of the methodology, after obtaining SotA. A set of procedural phases was established to perform this matching analysis.
1) Extraction of ontology entities. Basically, the ontologies are classified into modules and, within each module, a set of entities are included to represent “things.”
2) Definition of requirements from services in terms of data requirements For this purpose, datasets are compiled where the next piece of information is collected.
a. Dataset: Name of the dataset that represents the data to be used.
b. Functionality: Name of the service or functionality that makes use of the dataset.
c. Level/asset: Level of representation is required (e.g., building, plugs, heat pump).
d. Data collection: Data source from where the dataset was obtained (e.g., BMS).
e. Data origin: From where the data are measured, such as smart meter.
f. Dataset content: A short description of the content of the dataset, including data points (e.g., identifying thermal zones of a building or climate conditions (temperature, humidity, etc.) in a location).
3) Matching requirements into ontology entities. Figure 4 depicts this exercise, where each individual entity is mapped onto the YES/NO answer. An affirmative response means that the entity is needed and the ontology represents the dataset requirement, whereas a negative answer means that the entity does not appear for the dataset.
4) Selection of the most suitable ontology (Step 3 of the methodology) that brings most of the entities to be mapped into the requirements.
Figure 4. Matching the DR services requirements into the entities of the SotA ontologies.
Base ontology
As mentioned above, dCO1 was selected as the base ontology from which the DEDALUS ontology would be created. The dCO is a structured and formalized framework designed to enable interoperability and data sharing in smart building environments. Developed as part of the domOS project25, the main goal of this ontology is to provide a common vocabulary for representing information related to buildings, their energy systems, and various devices and services that interact within them.
The dCO ontology brings together multiple ontologies such as the Thing Description (TD) ontology, SAREF core ontology, SAREF4ENER, and the Building Topology Ontology (BOT). This enables the creation of a unified directory of information that allows IoT service providers to access and search for building-related metadata. To enhance its completeness, other ontologies have also been incorporated into the dCO. For instance, the Ontology of Units of Measure (OM) is included, offering a standardized method for representing and describing units of measurement and their relationships. OM is compatible with other ontologies such as SAREF4ENER, TD, and BOT and adheres to the (Web Ontology Language), RDF (Resource Description Framework), and international standards such as the SI and ISO for units of measure.
The W3C Thing Description (TD) ontology, developed by the World Wide Web Consortium (W3C) in 2020, was created to describe the features and capabilities of IoT devices and services. It defines a range of classes, properties, and relationships that capture not only the physical and functional characteristics of devices, but also their communication and security attributes. TD aligns with other ontologies, such as SAREF4ENER, facilitating the integration of IoT devices and services across different applications, regardless of the protocols they use or the manufacturers they originate from. This ontology makes it easier for developers to build applications that communicate seamlessly with various IoT devices.
The Building Topology Ontology (BOT) (used in this study due to its availability under the Creative Commons Attribution 4.0 International (CC BY 4.0) license), integrated into the dCO, is designed to describe the physical structure and layout of buildings, including their components and the spatial relationships between them. BOT's primary goal of BOT is to provide a standardized method for representing building data across multiple applications and domains. Built upon OWL and RDF standards, it integrates well with other ontologies, such as SAREF4ENER and TD. BOT is particularly useful for integration with Building Information Modeling (BIM) tools, such as Revit and IFC, facilitating import and export functions. While the BOT provides a detailed structural topology of buildings, it lacks the ability to describe systems, equipment, devices, and telemetry data. Therefore, alignment with ontologies such as Brick or SAREF is needed to cover these areas. This alignment was achieved within the DomOS project, which integrates TD, SAREF, SAREF4ENER, and BOT into a cohesive framework.
Extension to comply with DEDALUS requirements
As discussed earlier, the base ontology (dCO) was extended to meet the specific requirements identified by DEDALUS service developers (see Figure 4). To ensure that the ontology addressed their needs, a questionnaire was distributed to the DEDALUS partners, gathering insights into the data they required for their services. These data requirements were then cross-referenced with dCO, and a list of missing entities was identified, including solar radiation, storage capacity, state and state of charge (batteries), set-point, lighting, CO2, humidity, weather stations, smart plugs, charging stations, inverters, heat pumps, PV panels, regions, and zones.
Following the identification of these extensions, the next step was to look for existing ontologies that could provide these entities, because reusing ontological elements is the preferred approach when developing new ontologies.
As shown in Figure 5, entities regarding Key Performance Indicators (coming from the BIGG ontology) have been linked with saref:measurement. This connection ensures consistency between ontologies. Additionally, two new types of saref devices have been introduced: BIGG, WeatherStation, and Inverter.
Furthermore, because it was necessary to represent users within the ontology, the entities from the InterConnect ontology were integrated. In this case, the entity InterConnect:User is linked with a saref:task. According to the definition of dCO, Task entity represents "the goal for which a device is designed (from a user perspective).
Figure 5. Extending dCO Ontology (source of the initial image: 23).
Real application
Interoperability enablers
The proliferation of IoT devices has significantly increased both the volume and variety of data collected, presenting a major challenge: the lack of interoperability between disparate systems and platforms where data is stored. This barrier has been a key obstacle to widespread IoT adoption, as it complicates the seamless integration of data from multiple sources. Addressing these challenges, the FIWARE Foundation26, a non-profit organization, drives the definition and encourages the adoption of open standards to facilitate the development of interoperable, smart digital solutions across diverse domains, such as Smart Cities, Smart Energy, Smart Agriculture, and Smart Industry. FIWARE provides a suite of open-source components, named Generic Enablers (GEs), which can be assembled with other third-party modules to create platforms for building intelligent solutions in a fast, easy, and inexpensive manner. At the core of any “Powered by FIWARE” system is the FIWARE Context Broker GE, which enables the modelling, management, and retrieval of context information. This Context Broker supports Representational State Transfer (REST) Application Programming Interface (API) for interacting with contextual data and provides subscription-based notifications, thereby supporting the development of context-aware applications.
The FIWARE Next Generation Service Interface (NGSI) is an open standard for managing contextual data, initially established by the Open Mobile Alliance (OMA)27 in 2012 and subsequently enhanced by FIWARE, resulting in NGSI-v228. NGSI-v2 evolved and has been standardized into the new NGSI-Linked Data (NGSI-LD) version of the standard29 by the ETSI Industry Specification Group for crosscutting Context Information Management. The NGSI-v2 is ideal for creating individual applications that offer interoperable interfaces for Web services or IoT devices in isolated smart systems. Instead, NGSI-LD and Linked Data are used for managing situations requiring interoperability across apps and organizations.
The NGSI-v2 data model comprises Entities, Properties (or attributes), and Metadata. An Entity represents any physical or logical object, as a sensor or a room. Each Entity has an identifier and a type that describe the “thing” represented by the entity itself. An Entity can have one or more context Properties and each Property has a name (what type of property), a Property Type (NGSI value type of property value), and a Property Value (actual data). Properties have Metadata that are characterized by a Name (describing the role of the metadata), a Type (describing the NGSI value type of the metadata value), and a Value containing the actual metadata.
The NGSI-LD Information Model builds upon the core Meta-Model, which represents a formal specification of the foundation classes presented in the NGSI standard. Entity resource is the central class of the Meta-Model; an Entity is the virtual representation of a physical object in the real world and its centrality is highlighted by the role of the other resources, namely, the Property and the Relationship. As represented in Figure 6, the NGSI-LD classes of the Meta-Model, called resources, can be mapped to a standard Resource Description Framework (RDF) data model30; cross-domain ontologies, exemplified by location and temporal data, are represented to further demonstrate the extensibility of this model31.
Figure 6. NGSI-LD core meta-model and the cross-domain ontology31.
FIWARE offers several GEs in its Catalogue32, addressing the following:
Core Context Management manipulates and stores context data so that it can be used for further processing.
Interfacing with the Internet of Things (IoT), robots, and third-party systems to capture updates on context information and translate required actions.
Processing, analysis, and visualization of context information, implementing the expected smart behavior of applications, and/or assisting end users in making smart decisions.
Context Data/API management, security, publication, and monetization, bringing support to usage control and the opportunity to publish and monetize part of the managed context data.
NGSI Agents capture data from various devices using heterogeneous protocols and convert them into the NGSI standard platform language. Additionally, FIWARE supports libraries for creating custom NGSI Agents, empowering developers to design tailored solutions. These Agents also enable command transmission to devices, ensuring a two-way interaction.
Collaborative efforts by FIWARE, IUDX, TM Forum, and OASC have led to a joint program for supporting the adoption of compatible common data models, called Smart Data Models, that promote interoperability and replication of smart solutions across sectors33. These data models, available publicly and royalty-free, define harmonised representation formats and semantics, which can be used by applications for both consuming and publishing data.
Using the ontology within the interoperability enablers
The interoperability in DEDALUS is guaranteed by using the DEDALUS ontology as a building block for the definition of the vocabulary associated with the underlying data model. This ontology provides the basis for assigning unique identifiers to data entities and their relationships, thereby enabling computers to effectively interpret and connect disparate datasets.
To achieve a system that supports data integration across different platforms, JSON-LD can be exploited, a format that enhances JSON by adding a specific element called @context. This @context element allows the incorporation of unique long URIs for each data attribute, thereby removing ambiguity and ensuring consistency in data interpretation. By defining these URIs, developers can use short attribute names within their applications, while the system manages translation between these short names and their complete URI forms. This process guarantees that attributes remain uniquely identifiable, even if different systems use different attribute names.
As mentioned in the previous paragraph, in DEDALUS we followed the FIWARE approach, adopting an extension of JSON-LD, called NGSI-LD. This specific format plays a crucial role in ensuring semantic consistency across the data model used throughout the project. This is achieved providing a core @context that cannot be overridden, ensuring a consistent structure for data attributes and establishing an agreed-upon set of identifiers for entities and attributes. For example, the common concept of "temperature" within the project is associated to a definition associated with a specific URI, thus ensuring its meaning remains clear and consistent throughout various systems. Although not mandated by FIWARE, the availability of this URI as URL is generally preferred to facilitate ontology browsing. In this way, in DEDALUS, concepts are associated with URLs, such as "https://dedalus.org/ontology/temperature," as it follows:
"@context": {
"schema": "https://dedalus.org/ontology/",
"temperature": "schema:temperature"
}
This means that every temperature attribute follows the definition defined by the DEDALUS ontology (https://dedalus.org/ontology/temperature).
The usage of NGSI-LD and the @context definition derived from the DEDALUS ontology allows interoperability at IoT Agents level, as it can been seen in Figure 7. Orion Context Broker and connection between the IoT agents and the JSON-LD @Context. The IoT Agent acts as an intermediary between IoT devices and the Orion Context Broker, facilitating communication and ensuring that data generated by the devices is captured as context entities. During the "device provisioning" phase, the IoT Agent assigns unique IDs to unknown devices, linking each device to its measurements and ontological meaning. This setup allows the IoT Agent to add new measurements to the context and to ensure that each attribute of every device entity is represented in accordance with the supplied @context definition.
Figure 7. Orion Context Broker and connection between the IoT agents and the JSON-LD @Context (Derived from 34).
Once an IoT device has been provisioned, it can transmit data to the IoT Agent, which subsequently records it as NGSI-LD entities within the Orion Context Broker. MongoDB is used for the temporary short-term storage of these entities, ensuring that the context broker can make data available in an interoperable manner for third-party applications and services, utilizing standard APIs as specified by FIWARE's official documentation.
Conclusions
Interoperability remains a critical issue in modern building management systems, particularly with the increasing integration of smart technologies that rely on real-time data exchange. The lack of standardized communication protocols and data formats across systems, such as HVAC, lighting, and energy management, hinders the seamless coordination required for optimal building performance, energy efficiency, and demand response initiatives. As demonstrated, the adoption of standardized approaches such as SAREF and open standards such as MQTT can address some of these interoperability gaps, but do not fully resolve challenges related to semantic understanding and integration across diverse platforms.
This study highlights the importance of a structured and standardized ontology-based approach for ensuring interoperability in demand response programs. By utilizing the dCO ontology as a foundational framework and extending it to incorporate new entities and concepts required by the DEDALUS project, a more holistic, flexible, and adaptable system was created to support various building systems and devices. The DEDALUS ontology facilitates seamless communication among devices, systems, and services, contributing to improved energy efficiency and grid responsiveness.
Moreover, integrating existing ontologies, such as SAREF, OpenADR, and Brick, with dCO ensures that the system leverages established concepts and models while addressing specific requirements for demand response. This approach promotes the reuse of proven ontological structures, reduces development time, and fosters a more sustainable and scalable framework for future smart building applications.
The use of FIWARE’s NGSI-LD standard for context data management further enhances the interoperability of the DEDALUS Ecosystem. By adhering to open-source frameworks and leveraging the JSON-LD, the system enables dynamic and machine-readable data structures that improve compatibility across diverse applications and services. This enables building operators to harness the full potential of IoT devices and to make informed decisions based on accurate real-time data.
In conclusion, the standardized methodologies and tools discussed in this work provide a clear pathway toward achieving semantic interoperability for demand response, ensuring that systems not only communicate effectively, but also understand and process data in a meaningful and consistent manner. The adoption of these standards and frameworks is crucial for driving innovation, reducing energy consumption, and achieving long-term sustainability goals for building management and energy systems.
Ethics and consent
Ethical approval and consent were not required
