View source for D4.3 One-pager: Framework and Standards for Data Interoperability

{{Side box
| bodystyle = width: 250px; float:right; clear:right;
| title = EDIAQI Project
| image = [[File:onepager-image_250x250.jpg|200px|link=]]
| below =
'''Link'''
* '''[https://ediaqi.eu/sites/default/files/materials/D4.3%20Framework%20and%20Standards%20for%20Data%20Interoperability%20-%20Version%201.pdf  Report (pdf)]'''
}}

This deliverable presents the first version of the EDIAQI framework and standards for data interoperability. Its purpose is to define a common technical and semantic approach so that indoor air quality (IAQ) data collected in different EDIAQI pilots can be shared, accessed and interpreted in a consistent way. The framework combines machine-readable vocabularies, agreed data categories, open standards and open-source software components. This helps EDIAQI partners organise pilot data in a way that supports comparison, reuse and later analysis across the project.

== Why is this topic important? ==
Indoor air quality data are collected in different buildings, pilot sites and countries. These measurements may come from different sensors, monitoring units, sampling methods, software tools and data platforms. Without common data structures and shared terminology, it becomes difficult to compare results between pilot sites or to combine data for project-level analysis.

This deliverable addresses that challenge by defining a shared semantic and technical framework for EDIAQI data. In practice, this means agreeing on what is measured, how each parameter is described, which units are used, how often data are sampled and reported, and how measurements are linked to buildings, rooms, sensors and locations.

For pilot coordinators, technical partners and data users, interoperability makes the collected information easier to exchange, understand, validate and reuse. It also supports the wider EDIAQI goal of making project data more Findable, Accessible, Interoperable and Reusable.


== Key messages ==
* '''A common data framework is essential:''' EDIAQI pilot data need shared rules so that measurements from different countries, buildings and sensor systems can be compared and reused. This includes common parameter names, units of measurement, sampling and reporting information, and consistent identifiers for data elements.

* '''Measurements need context:''' Indoor air quality values are more useful when they are linked to the room, building and monitoring setup where they were collected. The framework therefore includes auxiliary information such as room use, occupancy, ventilation type, building characteristics, floor area, glazed surface area and sensor placement.

* '''SensorThings API is the core model for dynamic monitoring data:''' The OGC SensorThings API is identified as the main standard for sharing dynamic EDIAQI sensor data in a formalised and interoperable way. In this model, monitoring units or samplers can be represented as '''Things''', measured rooms or building parts as '''Features of Interest''', measured parameters as '''Observed Properties''', and individual measurement values as '''Observations'''.

* '''Open-source tools support implementation:''' The deliverable recommends a reference open-source software stack for implementing the interoperability framework. FROST-Server is recommended for SensorThings API services, PostgreSQL/PostGIS for storing measurements and spatial data, GeoServer for WMS and WFS services, and QGIS for browsing and analysing geospatial data.

* '''Spatial information is central:''' EDIAQI data are linked to specific locations, buildings, rooms and monitoring points. The framework therefore uses geospatial standards and tools to describe where observations are made and to prepare future links between monitoring data, building information and spatial models.

* '''This is a first version and further development is planned:''' D4.3 presents Version 1 of the interoperability framework. Further work is planned in D4.7, including discovery metadata, additional vocabularies, biological and toxicological parameters, lifestyle metadata from questionnaires, and further mapping towards CityGML or INSPIRE building data models.

== What did the EDIAQI project do? ==
The EDIAQI project team reviewed relevant open standards and technical specifications from international and European organisations, including OGC, ISO, CEN, W3C and INSPIRE. Based on this review, the project defined a first common approach for organising and sharing EDIAQI data.

The work covered both semantic interoperability and technical interoperability. Semantic interoperability focuses on the meaning of data: parameter names, units, measurement methods, reporting values and contextual information. Technical interoperability focuses on how data are exchanged between software components, databases and web services.

The project also mapped EDIAQI concepts to the SensorThings API data model. This included entities such as Things, Locations, Features of Interest, Sensors, Observed Properties, Observations and Datastreams. In addition, the project organised four training webinars between June and October 2023 to support partners in understanding and applying the selected standards and tools.



== What does this mean in practice? ==
The framework helps EDIAQI partners collect and share data in a consistent way across pilots and campaigns. It supports better comparison of measurements, clearer documentation of monitoring conditions and easier reuse of project data.

For non-technical users, the main practical value is that future indoor air quality information can be presented more consistently. For technical users, the value lies in having agreed standards, data models, vocabularies and software components for implementing interoperable data services.

{| class="wikitable sortable" style="width:100%;"
! style="width:25%;" | User group
! style="width:75%;" | Practical relevance
|-
| '''Homeowners and tenants'''
| The deliverable is not aimed directly at household users, but it supports the future development of clearer and more consistent indoor air quality information. Standardised units and parameter names can help avoid confusion when results are shown in dashboards or reports.
|-
| '''Schools and kindergartens'''
| The framework supports the structured collection of air quality data together with contextual information such as room type, occupancy and ventilation. This can make it easier to interpret IAQ monitoring results in educational buildings.
|-
| '''Commercial property owners'''
| Building owners and facility managers may benefit from more consistent monitoring data, especially when measurements are linked to room characteristics, sensor placement and building information.
|-
| '''Local municipalities'''
| Municipalities responsible for public buildings may benefit from standardised data structures when comparing measurements across schools, kindergartens, offices or other public facilities.
|-
| '''EDIAQI technical partners'''
| The framework provides practical guidance on how to structure, encode, share and access EDIAQI pilot data using open standards and open-source tools.
|}

== Recommendations ==
* '''Use the agreed EDIAQI data structure:''' Organise pilot data into metadata, measured data and auxiliary data so that measurements can be interpreted in context.
* '''Apply shared vocabularies:''' Use the identified EIONET, ECHA and INSPIRE/GEMET references where applicable to describe pollutants, units, measurement methods and building use.
* '''Use SensorThings API for dynamic sensor data:''' Dynamic measurements from monitoring systems should be mapped to the SensorThings API model wherever relevant.
* '''Document the measurement context:''' Air quality values should be accompanied by information about the room, building, occupancy, ventilation type and sensor placement.
* '''Follow EDIAQI naming conventions:''' Use consistent identifiers for Things, Locations, Sensors, Features of Interest and Datastreams to avoid ambiguity in the data platform.
* '''Prefer open-source components where possible:''' FROST, PostgreSQL/PostGIS, GeoServer and QGIS are recommended reference tools for implementing the framework.
* '''Prepare for later metadata and building-model integration:''' Pilot teams should consider how their data could later be connected to discovery metadata, CityGML or INSPIRE Buildings models.

== Limitations ==
This deliverable represents the first version of the EDIAQI interoperability framework. At this stage, the semantic framework focuses mainly on physical and chemical air quality parameters.

Several elements are planned for later development. These include indoor biological parameters, indoor toxicological parameters, lifestyle metadata from questionnaires, additional outdoor air pollution semantics from external sources, discovery metadata for making data more findable, and further mapping towards CityGML or INSPIRE Buildings models.

The document is mainly technical and is intended to guide the organisation, exchange and reuse of data. It does not provide health-based threshold values, direct policy recommendations or detailed instructions for improving indoor air quality in buildings.


<div style="color:#202122; font-size:1.5em; font-weight:normal; border-bottom:1px solid #a2a9b1; margin-top:1.2em; margin-bottom:0.4em; padding-bottom:0.2em;">
'''Related wiki pages'''
</div>
* [[Sensors]]


<div class="mw-collapsible mw-collapsed" style="border: 1px solid #ccc; padding: 10px; background-color: #f9f9f9;">
'''[+] View technical source and page metadata'''
<div class="mw-collapsible-content">

<div style="color:#202122; font-size:1.5em; font-weight:normal; border-bottom:1px solid #a2a9b1; margin-top:1.2em; margin-bottom:0.4em; padding-bottom:0.2em;">
Source deliverable
</div>
This one-pager is based on:
* '''Deliverable:''' D4.3 – ''Framework and standards for data interoperability – version 1''
* '''Work Package:''' WP4 – Pilots, data and campaigns
* '''Lead partner:''' DEDA / DedaNext
* '''Original deliverable type:''' R – Document, report
* '''Dissemination level:''' PU – Public
* '''Official submission date:''' 30 November 2023
* '''Actual submission date:''' 15 December 2023


</div>
</div>