# Enabling Biodiversity-Informed Architecture Through Ontology-Driven Data Integration
## 5 Ontology-Driven Data Integration Through OBDM  
We used a triple store as an implementation for OBDM, specifically GraphDB, which supports modes of virtualisation via Ontop integration [43] and materialisation (natively). This approach is versatile, as the virtualised data can also be materialised to enhance query performance. OBDM [5] was chosen for its ability to provide semantic interoperability, reasoning, and data virtualisation, ensuring a flexible and scalable approach to integrating heterogeneous data sources. Unlike traditional ETL-based data integration, which requires extensive preprocessing and rigid schema mappings, OBDM allows for query federation, enabling real-time access to distributed data without duplication. For these reasons, we chose to virtualise the voxel model. By aligning with FAIR principles, OBDM enhances data findability, accessibility, interoperability, and reusability, making it particularly suited to complex domains like urban ecology and sustainable architecture. Additionally, GraphDB's mature implementation of OBDM supports efficient query execution and reasoning, further strengthening its suitability over conventional integration techniques. In GraphDB, one can configure a repository (equivalent to a database) by choosing one of the modes. Then, one can combine the results of the two modes by using query federation in SPARQL via the SERVICE keyword. As we have explained previously (cf. Figure 2), the voxel model is virtualised using OBDA mappings. The implementation of OBDA mappings in RDF is provided in Figure 5. The set mappings for voxel data are provided 1-1 (one-to-one), meaning that each column from the voxel data is mapped to a unique property in RDF, i.e., \(vox\_x\leadsto\leavevmode\
obreak\ :\leavevmode\
obreak\ x,vox\_y\leadsto\leavevmode\
obreak\ : \leavevmode\
obreak\ y\), and so on. Keeping the mapping expressivity lean makes it future-proof for future use cases, namely in cases where updating voxel data is needed from the ontology via SPARQL update queries without the need to resolve ambiguous mappings and the side-effect of running into the _view update_ problem, which is known in database theory [14]. \begin{table}
\begin{tabular}{c c c c c c} \hline
**Dataset No.** & **Spatial** & **Input Format** & **Mapping Language** & **Triple Count** & **Storage Mode** \\ \hline
1. & (x) & CSV & Ontotext Refine & 3548 & Materialised \\
2. & x & shapefile & RML & 881 & Materialised \\
3. & (x) & CSV & Ontotext Refine & 2,454,463 & Materialised \\
4. & x & CSV & Ontotext Refine & * 492 & Materialised \\
5. & - & JSON & RML & 256 & Materialised \\
6. & (x) & PDF & - & **34** & Materialised \\
7. & (x) & CSV & Ontotext Refine & * 2858 & Materialised \\ \hline
8. & - & RDF & - & 136,865,946 & Federated \\
9. & (x) & RDF & - & *** 3,889,978 & Federated \\
10. & (x) & RDF & - & 5,363,877 & Federated \\ \hline
11. & x & - (CAD metadata) & Grasshopper components & *** 20 & Materialised \\
12. & x & RDB & OBDA & 1,329,096 & Virtualised **** \\ \hline \end{tabular}
\end{table} 
Table 2: The datasets that are mapped and integrated into the ECOOPES KG. The system allows for defining the sources (the voxel model stored and managed in the relational database) and mapping definitions (OBDA or R2 RML ([[https://www.w3.org/TR/r2](https://www.w3.org/TR/r2) rml/]([https://www.w3.org/TR/r2](https://www.w3.org/TR/r2) rml/), accessed on 17 March 2025)), thereby exposing it as a separate repository in which SPARQL queries (via SERVICE keyword) are translated into SQL queries, respectively, on the fly via query unfolding (cf. Figure 6). For the time being, we have used the native OBDA mappings; in the future, we plan to replace this with the more future-proof R2 RML mapping language. The integration scenario in Figure 7 showcases the OBDM, namely the combination of virtualisation and materialisation in the context of the CAD and Grasshopper environments. The federated query using the SERVICE keyword issues the query to the repository where the mappings and virtualisation are applied.