Urban biodiversity is essential for sustainable cities, as it helps address the challenges of environmental degradation, ecosystem loss, species decline, and increased vulnerability to climate hazards, which negatively afect human health and well-being. ECOLOPES (ECOlogical building enveloPES) aims to develop a design approach for multi-species as stakeholders to achieve regenerative urban ecosystems. Integrating the diverse data required for stakeholders and beyond-spanning life sciences, geography, and architecture-and utilizing it for design presents a significant challenge. This paper introduces an innovative ontology-driven approach that integrates diverse data sources, enabling ecologists and architects to design sites and buildings that foster urban biodiversity. The proposed ontology, developed in collaboration with domain experts and adhering to Semantic Web best practices, serves as a mediator between life sciences data (e.g., species distribution and habitats) and geometric information (e.g., maps, voxel models of building structures). This integration enables the adaptation of site, buildings and geometries respectively to create habitats that attract and support urban wildlife, contributing to ecological sustainability. The paper illustrates the practical utility of the ontology through a case study, highlighting its role in guiding building designs that promote species attractiveness and urban biodiversity.
The expansion of urban areas, and the resulting decline in natural spaces, has led to new challenges,
including ecosystem degradation, species loss, and increased vulnerability to climate hazards among
others. Urban biodiversity is essential for sustainable cities, as it helps address the challenges, which
negatively afect human health and well-being. ECOLOPES (ECOlogical building enveloPES), an H2020
FET Project, aims to develop a design approach for multi-species—plants, animals, microbiota and
humans—as stakeholders to achieve regenerative urban ecosystems [
Designing with multi-species in mind and implementing the requirements from a design brief, from both architecture and ecological point of view, presents a significant challenge. The problem is exacerbated considering that species have their unique requirements (e.g. solar), distance measures in respect to other species (e.g. prey areas), as well as distances in relation to other architectural objects (e.g. nesting). In order to reduce the complexity level for the designer, the translation of the design brief need to be represented in a more abstract form as a layer of translation that can be easily changed or guided. In order to tackle this problem, we use a network of nodes, i.e., network configuration , representing the requirements comprised of predefined ‘circle shapes’ of EcoNodes (denoting species) and ArchiNodes (denoting buildings or other architectural objects), which can be placed in the CAD environment by the designer (cf. Fig. 1).
The placement of nodes need to be well-informed by encapsulating and integrating diverse data required for stakeholders and beyond—spanning life sciences, geography, and architecture—and utilizing it for design. Data sources range from publicly available datasets, which can be easily accessed and retrieved via web APIs—such as GLoBI (Global Biotic Interactions for species) [2]—to private datasets generated within ECOLOPES, including Plant Functional Groups (PFGs) [3], and voxel data [4] that capture site-specific variables like coordinates, aspect, slope, or solar radiation. Ontologies and knowledge graphs provide a means of integrating data sources in a machine-readable form, complying with FAIR principles, that can be leveraged by a decision support system for the placement of nodes. By applying Semantic Web and Linked Open Data (LOD) principles data from diferent datasets can be linked, e.g. when species in diferent datasets referring to the same entity.
The resulting heterogeneous data requires integration, alignment, and consolidation into a unified RDF-based graph data model, with ontological terms used to define the mappings. We note that the network configuration can be easily represented as a graph data model. The outcome is a knowledge graph [5, 6] that contains curated and contextualized knowledge, enabling holistic querying and answer retrieval through the use of domain ontologies. Considering the high volume of voxel data, we have employed Ontology-based Data Access (OBDA) [7] as a data integration framework. This approach led to some data being virtualized (e.g., voxel model), while the remaining data was materialized, i.e., stored and consequently indexed by the triple store. This approach is pragmatic as the data is not moved as well as no data duplication is created, albeit with downside of performance in query evaluation.
The scope of the knowledge graph is often determined by the set of competency questions (CQs)[8] it is designed to answer, e.g.: “Provide me with the local species that are known to have the protection status threatened?”. We can contextualise a CQ in our setting: “Provide me the locations in site where I can place the plant Abies alba (EcoNode) such that its solar requirements are met?”. To answer the CQs, new data need to be ingested and harmonised, such as public data on local species provided by municipalities, citizen science (e.g. GBIF1), and threatened species data from International Union for Conservation of Nature (IUCN)2.
The computational model that we have employed to generate design outcomes and their validity, based on the designer’s input is rule-based. This approach computes the design outcomes based on the selected rules that can be run in a designated order, namely solar radiation and proximity constraints. Our implementation mimics a rule-based reasoning by employing a set of SPARQL queries [9] for the (selected) rules that are run in a sequence and are orchestrated by the Grasshopper environment (cf. Fig. 1).
To summarise, this paper introduces an innovative ontology-driven approach that integrates diverse data sources, enabling ecologists and architects to design sites and buildings that foster urban biodiversity. Proposed ontology-aided design methodology builds up on the concept of performance-oriented design [10, 11] and the conceptual framework focused on data-driven approaches to understanding and designing environments [12]. The paper illustrates the practical utility of the ontology through a case study, highlighting its role in guiding building designs that promote species attractiveness and urban biodiversity.
Our contributions are: • A new EIM (Ecolopes Information Model) ontology and knowledge graph in the domains of architecture and ecology. • A method based on OBDA to map and integrate diferent data sources stemming from diferent environments from the respective domains. • A designer workflow in which the designer is getting feedback (e.g. fulfillment of solar radiation or proximity constraints) or ask CQs against the KG.
The rest of the paper is structured as follows. In Sec. 2 we provide the necessary background, preliminaries and related work. In Sec. 3 we explain the ontology design, reuse and alignment. In Sec. 4
2https://iucn.org we discuss the data integration framework used for integrating the heterogeneous data sources. In Sec. 5 we describe the demonstrator and we provide the results achieved in that context. And, finally in Sec. 6 we conclude the paper with conclusions and future work.
The ontology-aided generative computational design process facilitates design generation, namely of the search space populated with alternative design solutions that can be analysed and evaluated. The overall process of design generation entails synthesising heterogeneous ecological, environmental, and architectural data, voxel-based data structuring, context-information at regional/urban and local/architectural scales, and modeling information according to decision needs.
The role of the ontologies is to model information regarding the entities and relationships that need to be represented and to aid the design of ecological building envelopes. We distinguish between ontologies as schema TBox and instance data as ABox. More formally, for a given data source and its variables x we create ABox by applying a set of mappings: x E(f (x)), where E is a TBox class or property, f (x) is a set of IRI templates, e.g. https://resource.dap.tuwien.ac.at/network/{ID}, each applied to the variable x in order to create a Literal or IRI. Knowledge graph KG is union of ABox and TBox3, and typically stored (materialised) in a triple store. A (part of) ABox can be virtualised instead of being materialised depending on the use case requirements. In this particular case, the mappings that are represented in a specific mapping language are used to translate the queries on the fly back to the original data sources. TBox axioms are used to infer new implicit triples in ABox based on asserted (ABox) triples, which are either stored in the triple store, or alternatively query is rewritten during the query time with respect to TBox axioms to account for the same (query) answers. The latter does not hold for very expressive OWL ontology languages, but rather for (minimal) RDFS, consisting of domain/range, subClassOf and subPropertyOf axioms [13].
The role of the voxel model within the ontology-aided design process is to structure and spatialize datasets describing the real-world location in which the design process is taking place. Based on an extensive literature review of the voxel models’ role in the engineering fields [ 4], an early definition of voxel models as "knowledge representation schemata" [14] was established in the context of computational design. Voxel model implementation developed for this study extends the Composite Voxel Model methodology [15] to incorporate the explicit link with the knowledge representation through the ontology-aided design process. The implemented ECOLOPES Voxel Model contains data describ3Herein, we also distinguish taxonomies or controlled vocabularies as a part of KG, sometimes referred as CBox. They are essential to capture hierarchical representations, e.g., animal ranks. ing the real-world site’s physical geometry and environmental performance. Currently, voxel-based design approaches addressing anthropogenic landscape adaptations can be found [16], and studies aiming to integrate voxel- and ontological modeling are ongoing [17]. The presented implementation of the ECOLOPES Voxel Model is unique since it operates in the relational database environment (PostgreSQL), providing the implemented EIM Ontology with direct access to voxel data through the OBDA bindings. As indicated in Fig. 2, datasets provided by the ECOLOPES Voxel Model are structured as voxel data layers. Currently raw, aggregate and filtered data layers are exposed in the EIM Ontologies, enabling interactive temporal resolution change of the environmental simulation data contained in the ECOLOPES Voxel Model. For example, existing data describing monthly average sunlight exposure can be aggregated to create five additional data layers. Those layers represent average sunlight exposure (sunlight hours) in summer, autumn, winter, spring and in the growing season. Designers can retrieve voxel data, including geometry and all available parameters, stored in diferent levels that represent diferent scales and resolutions, which are exposed as a SPARQL endpoint (see Sec. 4).
Two processes are combined in the ontology-aided generative computational design process: (i) the translational, and (ii) the generative process.
In the translational process the designer analyses, correlates, and locates spatially architectural and ecological requirements contained in the design brief, and design-specific determinations, while taking into consideration relevant constraints (i.e. as given by planning regulations). In order to do so, the designer uses a set of predefined Nodes and places them in the CAD environment in order to satisfy ecological and architectural requirements. Herein, the designer can query the knowledge graph in order to get feedback regarding the solution space regarding permissible design outputs, in terms of satisfying the proximity distances between Nodes (e.g. species) or solar radiation requirements. Knowledge graph is also a mediator with the voxel model (cf. Fig. 2) that contains prepared datasets regarding environment variables (including geometric). In this paper we focus on the translation process only. The intended goal of the translational process is shown in Fig. 1.
The generative process consists of two distinct stages. In the first stage, the variations of spatial organisation are generated and evaluated. In the second one, specific surface geometries are generated for selected outputs of the previous stage and evaluated according to defined criteria, i.e. key performance indicators. The generative process falls outside the scope of this work and is planned for future
Related Work The use of Semantic Web technologies and OWL to represent ecological network specifications is explored in [ 19]. Ecological networks capture the structure of existing ecosystems and provide a basis for planning their expansion, conservation, and enhancement. An OWL ontology is employed to model these networks, enabling reasoning about potential improvements and identifying violations in proposed network expansions.
Global Biotic Interactions (GLoBI) [2] is an open-access platform designed for researchers, aggregating diverse datasets to provide comprehensive information on species interactions, such as predator-prey, pollinator-plant, and parasite-host relationships, among others. GLoBI ofers both an API and a SPARQL endpoint (with partial data coverage) for accessing species interaction data in CSV or RDF formats. Species data is structured using the Darwin Core4 vocabulary, with equivalence between species established through owl:sameAs relations. Additionally, the platform features a web-based frontend application that supports species searches via text and/or geographical boundaries. The OBO Relations5 ontology can be leveraged for reasoning to infer implicit interactions based on explicit triples.
Nature FIRST KG [20] is a knowledge graph consisting of taxonomies that connect habitats, species and Natura 2000 areas by using so-called “crossovers” via SKOS or bespoke OWL properties. The KG describes diferent aspects of ecologically-related knowledge obtained from European Environment Agency (EUNIS)6, IUCN, where diferent versions of habitats are connected each containing diferent contextual knowledge and crossover relations to species.
The integration of ontologies and knowledge graphs has gained prominence in urban ecology for their ability to model complex interactions between built environments and natural ecosystems [21]. These semantic technologies are widely applied across Architecture, Engineering, and Construction (AEC(O)) and Urban Planning to enhance data interoperability, life-cycle management, and sustainability [22, 23, 24]. In the AEC(O) domain, ontologies support structured data exchange in building modeling, optimize construction processes, enable intelligent building automation, and facilitate sustainability assessments by integrating certification standards with performance data [ 25]. At the urban scale, they enhance digital twins and infrastructure management through semantic city models, support environmental planning via sustainability ontologies, and model green and blue infrastructure for biodiversity and ecosystem services assessment [26, 27, 28]. Further applications include enabling multidomain simulations, integrating vegetation and biodiversity data for urban green space management, and structuring urban sustainability indicators for performance monitoring [29, 30]. Despite these advancements, challenges remain in harmonizing ontologies across domains, ensuring scalability, and developing robust reasoning mechanisms for automated decision support.
In contrast to the approaches reviewed in this section, our proposed ontology is specifically designed to bridge the gap between the distinct domains of ecology and architecture, enabling the seamless integration of heterogeneous data sources, complying with FAIR principles. Beyond serving as a conceptual model, the ontology also supports semantic reasoning and decision-making. This empowers stakeholders to uncover new insights, infer implicit knowledge, and make informed choices in the context of sustainable urban development and biodiversity-aware architectural design.
Ontologies, particularly those built using OWL7 (Web Ontology Language), not only provide a comprehensive description of a domain but also enable the inference of new implicit facts (i.e., RDF triples) based on the explicit facts asserted in the knowledge graph. In our case, we have modeled EIM Ontologies using a top-down conceptualization, a bottom-up approach informed by the data, and by reusing 4https://dwc.tdwg.org 5http://obofoundry.org/ontology/ro.html 6https://eunis.eea.europa.eu 7https://www.w3.org/TR/owl2-overview/ structures from well-established ontologies, namely OBO Relations [31] or Darwin Core8 following ontology construction best practice.
EIM Ontologies developed in collaboration with domain experts and adhering to Semantic Web best practices, serves as a mediator between life sciences data (e.g., species distribution and habitats) and geometric information (e.g., maps, voxel models of building structures). They are an interface with CAD and aids the design of ecological building envelopes addressing the critical “data-to-design gap” [32][21] in computational architecture and multi-species architectural design.
We organized a collaborative workshop with experts from the Ecolopes consortium, comprising architects and ecologists, to define the ontology and knowledge graph requirements. The participants were divided into four interdisciplinary teams, each consisting of six people, to encourage “cross-pollination” of ideas. Each team was tasked with defining a comprehensive set of CQs spanning both domains, which were written on post-it notes to foster discussion and iterative refinement.
In parallel, participants identified key concepts and relationships relevant to answering the CQs, writing them on post-it notes to form the foundation of the ontology. Where possible, they proposed synonyms, grouped concepts into categories, and outlined hierarchical relationships, efectively constructing initial ontological classes and subclasses. Teams were encouraged to identify potential properties linking concepts and to define attributes that could enrich the representation of data.
When participants could not fully define the ontology structure, they contributed by suggesting datasets or external sources that could address specific CQs, ensuring the ontology’s relevance and grounding in real-world data. This bottom-up approach resulted in a draft skeleton of the ontology, comprising initial classes, properties, and attributes. The output serves as a robust starting point for iterative ontology development, ensuring it aligns with the goals of integrating ecological and architectural knowledge.
Requirements were captured through CQs, to name a few: Which species we want/don’t want to attract close to our building? Which species are in PFG herbs_3? Which species that colonize the building are protected? Which species are invasive in this location? Which species can reach or live on sloped surfaces? What is the soil depth required for PFG herbs_3?
After the CQs have been defined they were grouped based on similarity and prioritized based on importance. After the screening and processing of the CQs, we could extract general (i.e. upper level) requirements from them. In this paper, considering that processing of all CQs is out of scope, we will focus only on general constraints and requirements that are pertaining to: • Proximity between architectural objects and species (and vice versa), or between species only. • Solar radiation (regarding species).
• Prey areas in CAD environment, which denote areas that species are allowed to prey on.
The ontology9 was developed following Semantic Web best practices, ensuring alignment with the FAIR principles. The methodology included the following core activities: • Iterative design and refinement with input from domain experts and ecological datasets. • Modular construction to enhance scalability and reuse. • Leveraging established vocabularies and ontologies, such as GeoSPARQL for geographical information and Darwin Core for biodiversity data.
9https://github.com/aahmeti/Ecolopes
Protégé is used as a tool to manage ontologies and taxonomies, while GraphDB to manage the KG instance data. The consistency checks provided internally by Protégé have been leveraged to ensure that the ontology is consistent in respect to modeling. From the modeling perspective, we have kept the approach lean by relying mainly on RDFS, with only few OWL axioms incorporated. For ontologies, modularisation has been applied, and accordingly a prefix scheme for ontologies, taxonomies and instance data has been defined facilitating accessibility and reusability. In the end, the ontologies are also imported in GraphDB and stored in separate named graphs. The repositories are configured with reasoning enabled, and for governance reasons development and production environments are distinguished. GraphDB allows for querying of derived implicit triples based on querying of the graph FROM <http://www.ontotext.com/implicit> 10.
In the following are given the set of prefixes used in describing instance, taxonomy and ontological data, implying the same set of prefixes for describing and CRUD operations. The modularisation networks-schema: vs ecolopes-schema: is used to delineate the respective ontologies that are used to represent diferent environments, i.e. networks vs ecolopes (cf. Fig. 5).
PREFIX networks −schema : < h t t p s : / / schema . dap . tuwien . ac . a t / network #> PREFIX networks − i n s t : < h t t p s : / / r e s o u r c e . dap . tuwien . ac . a t / network / > PREFIX networks − t a x o : < h t t p s : / / taxonomy . dap . tuwien . ac . a t / network / > PREFIX e c o l o p e s − i n s t : < h t t p s : / / r e s o u r c e . e c o l o p e s . org / > PREFIX e c o l o p e s −schema : < h t t p s : / / schema . e c o l o p e s . org #> PREFIX ofn : < h t t p : / / www. o n t o t e x t . com / s p a r q l / f u n c t i o n s / > PREFIX obo − ro : < h t t p : / / p u r l . o b o l i b r a r y . org / obo / > PREFIX dwc : < h t t p : / / r s . tdwg . org / dwc / terms / > PREFIX geo : < h t t p : / / www. o p e n g i s . n e t / ont / g e o s p a r q l #>
The ontology’s core concepts address the integration of ecological, architectural, and geographical data. Key classes include: • Classes: Archi- and EchoNode, Voxel, PlaneConstraint, SolarConstraint, and more. • Relationships: nodeHasDistanceToNode, nodeHasSpecies, nodeHasArch, nodeOverlapsPlane, and more. • Attributes: x, y, z, proximityRequirementMin, proximityRequirementMax, solarRequirementMin, solarRequirementMax, and more.
Reusing standards enhances the ontology’s integration with external datasets and systems, supporting its applicability across diverse domains. To ensure interoperability, the ontology aligns with established standards and vocabularies: • OBO Relations: For describing species interaction, i.e., predator-prey. • Darwin Core: For species metadata, ensuring compatibility with life sciences data. • GeoSPARQL: For representing geographical data, enabling spatial queries.
GLoBI employs OBO Relations to describe species interactions and their hierarchical order based on rdfs:subPropertyOf axioms, which can be leveraged for reasoning. Darwin Core is a widely recognized standard for capturing species metadata and species taxonomic rank (dwc:genus, dwc:order, and so forth), while the GeoSPARQL vocabulary provides a framework for representing spatial datasets in RDF. GeoSPARQL query language can be used as a standard for querying the RDF spatial datasets.
The alignment of OBO Relations has been done by adding owl:equivalentProperty relations, while keeping the existing GLoBI data not subject to data wrangling (cf. Fig. 3). As shown in the figure, given the relatively small number of properties, ontology matching was performed manually. Using SPARQL queries, we verified that all properties occurring in the instance data have resp. matches. 10https://graphdb.ontotext.com/documentation/10.8/query-behavior.html#tuning-query-behavior
Currently a number of datasets have been identified and integrated in the KG using the defined ontological classes, properties or attributes; namely: • Vienna local plants (CSV): plants, metadata and solar requirements. • Vienna local species (shapefile) : primarily, birds metadata (nesting boxes)11. • GBIF citizen science (API): local species filtered based on geographical coordinates. • Plant Functional Groups (CSV): internal dataset generated via the Ecological Model [3]. • Animal Functional Groups (JSON): internal dataset generated via the Ecological Model. • Animal-aided design (PDF): specifying the constraints between species and various architectural objects, used as a placeholder. • GLoBI (API): Global biotic interactions between species described in OBO Relations. • GBIF species (RDF): query federation of species including metadata details such as taxonomic rank described in Darwin Core12[33]. • Wikidata (RDF): query federation of species including metadata details, synonyms, common names, crossovers to many datasets including DBpedia, Catalogue of Life and so forth13. • CAD environment: Rhino CAD and Grasshopper environments.
• Voxel model (RDB-RDF): query federation of voxel model (cf. Sec. 2).
Heterogeneous data is mapped and converted into a graph representation in KG (ABox) by using diferent mapping languages such as RML, Ontotext Refine and OBDA 14. Shapefiles are converted to GeoSPARQL vocabulary in RDF using RML mappings that are generated by GeoTriples [34]. Some of the data is virtualized meaning data is not materialised (voxel model), while the remaining data is materialised. The user can query the KG using SPARQL as a unified interface that encompasses and integrates diferent datasets combining the results, and, if required, reasoning on top using TBox statements. Therefore, the KG integrates heterogeneous data from diferent sources, providing unified access to the data by using the SPARQL query language.
For the implementation of the virtualisation we use Ontop [35] module that is available within GraphDB triple store. The system allows to define the sources (voxel model stored and managed in the relational database) and mapping definitions (OBDA or R2RML 15), thereby exposing it as separate repository in which SPARQL queries (via SERVICE keyword) are translated to SQL queries respectively on the fly. For the time being, we have used the native OBDA mappings, and in the future we plan to replace with the more future proof R2RML mapping language. 11Provided by city of Vienna https://www.wien.gv.at/umweltschutz/umweltgut/ 12http://graph.openbiodiv.net 13https://query.wikidata.org 14https://graphdb.ontotext.com/documentation/10.8/virtualization.html 15https://www.w3.org/TR/r2rml/
Figure 5 shows a snapshot of the KG, which links knowledge from datasets originated in Grasshopper (left), global biotic interactions and proximity constraints (centre), voxel model (top) and PFGs (right). One can traverse from one context to another given that the relations between datasets are explicitly encoded (e.g. owl:sameAs), or they can be inferred by SPARQL queries (e.g. if x,y,z coordinates in-between datasets coincide). Whenever possible for URIs of species we treat Wikidata identifiers as canonical URIs, and provide crossovers via owl:sameAs to other linked datasets.
In the following we demonstrate the application and utility of the ontology and KG in a specific context in Vienna, in the site of the Nordbahnhof Freie Mitte location. Local species around the site are curated and provided by Vienna municipality, and in addition can be obtained from GBIF API (cf. Fig. 6) - albeit with the common data quality issues prone in the common citizen science approaches.
The pipeline (cf. Fig. 7) that we will describe in the following, consists of various steps, starting with cleaning, mapping of the network consisted of Nodes in JSON-LD serialisation16, preparing and pushing data to GraphDB, and finally the computation of the validation. Before every run, the data is cleaned (DROP GRAPH via curl command) using Grasshopper, in order to account for the changes in the CAD environment. The rationale for choosing JSON-LD lies on the fact that JSON-LD is compatible with JSON, and the Grasshopper components could operate using JSON data as a well-established standard. Mapping of Voxel Data Layers in EIM Ontology Voxel model contains environmental data on the specific site of Nordbahnhof. sunlightHoursSummer and sunlightHoursGrowingSeason properties map voxel data layers in the respective ontology attributes. For instance, designer places an EcoNode, defines its subType as Plant, and sets commonSpeciesName as “Silver fir”. Ontology stores mappings between commonSpeciesName (“Silver fir”) and latinSpeciesName (e.g., Abies alba), along with additional plant datasets and respective metadata. Consequently, sunlight requirements (solarRequirementMin and solarRequirementMax) are retrieved for the given EcoNode. Validation Process for EcoNodes and ArchiNodes Compares sunlightHoursGrowingSeason from the ECOLOPES Voxel Model with solarRequirementMin and solarRequirementMax. Returns a boolean value (?isValid) as the result of the comparison. Designer places an ArchiNode and defines its subType as Infrastructure or Building. Similar validation and mapping processes are outlined for ArchiNodes, including the prey area that is predefined by the designer as a rectangular shape. Rule-based process is based on CONSTRUCT queries for the respective solar, proximity and prey areas constraints. In Fig. 8 one can see the query for the proximity constraint. The CONSTRUCT query is transfored to an INSERT query in order the validation data to not only be computed but also materialised. The query takes into account multiple proximity constraints between diferent nodes n, in the range of O(n2) computational complexity. Variable ?res computes the Euclidian distance between nodes using GraphDB’s math functions17.
Preparing and Sending Network Data Reads data stored as key-value pairs from Rhino Objects representing Network Nodes. Rhino Point geometry created via the PlaceArchiNode and PlaceEcoNode commands (cf. Fig. 9). These are used to prepopulate Nodes based on a selection. Converts and outputs data to JSON-LD matching the ontology (TBox) schema. Sends JSON-LD formatted Network Node data to the GraphDB environment.
Define Evaluation Constraints Enables the designer to select constraints for validating the network configuration created in Rhino. One can choose as input Solar or Proximity constraints to be validated against, cf. Fig. 10 for visualisation of the validation, which is stored in GraphDB. The final output is a boolean answer that is computed by the AND (“join”) intersection of constraints using MIN operator. 17https://graphdb.ontotext.com/documentation/10.8/sparql-ext-functions-reference.html#mathematical-function-extensions
This paper presented an ontology-driven approach to integrate diverse datasets from public APIs, private sources, and CAD environments into a unified RDF-based knowledge graph, facilitating ecological building design. By leveraging OBDA, the approach balances virtualization and materialization, ensuring eficient data integration while supporting advanced queries and reasoning. The ECOLOPES ontologies bridges life sciences and geometric data, enabling designers to address ecological constraints like solar radiation and proximity through interactive workflows. A case study highlighted the ontology’s practical application in designing habitats that promote species attractiveness and urban biodiversity. For future work, we plan to use SHACL to define constraints, use a rule language instead of SPARQL queries in order to adhere to Semantic Web standards. More importantly to extend the problem setting towards generative process (geometric articulation) of the ontology-aided generative computational design by employing more sophisticated approaches akin to answer set programming.
This work is funded by the European Union Horizon 2020 Future and Emerging Technologies research project ECOLOPES: ECOlogical building enveLOPES (grant number: 964414). The funding source is not involved in the conduct of the research or preparation of the article. Furthermore, we extend our gratitude to Mariasole Calbi for kindly providing the PFGs dataset, to Victoria Culshaw for sharing the AFGs dataset, and to Navid Javan for assisting us with the Grasshopper workflow and components.
During the preparation of this work, the authors used ChatGPT, Grammarly in order to: grammar and spelling check, paraphrase and reword. After using this tool/service, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content. G. Xiao, Ontop: Answering SPARQL queries over relational databases, Semant. Web 8 (2017) 471–487. [36] D. Mouromtsev, D. Pavlov, Y. Emelyanov, A. Morozov, D. Razdyakonov, M. Galkin, The simple web-based tool for visualization and sharing of semantic data and ontologies, in: International Semantic Web Conference (Posters & Demos), 2015.