2.4.1. Environmental observations data

The Met Office DataPoint API provides open access to both weather observations and forecasts (e.g., temperature, wind speed and direction, humidity, etc.) for thousands of stations across the UK (Met Office, 2022). While forecasts cover a 5-day period, actual observation values are provided for the previous 24 hours. Similarly, the UK Air Information Resource (UK-AIR) provides real-time air quality data for various pollutants via a machine-readable Sensor Observation Service (Department for Environment, Food, and Rural Affairs, 2023), including nitrogen dioxide, particulate matter, and ozone. The Environment Agency (EA) provides several API endpoints with (near) real-time information related to flooding and flood risk: The Real Time flood-monitoring API (Environment Agency, 2021b) provides a continuously updated list of current flood alerts and warnings, together with applicable flood areas, as well as live readings of water levels and flows recorded at various measuring stations along rivers and other water bodies. Furthermore, precipitation and hydrological data about river levels, river flows, groundwater levels, and water quality are provided via EA’s Hydrology API (Environment Agency, 2021a). As the official government agency responsible for environmental protection and regulation, EA operates its own UK-wide monitoring system to collect river level, hydrological, and rainfall data. With regards to flood risk management, EA deploys a widely recognized early warning dissemination system as part of its flood risk reduction and adaption strategy, including proactive communication to the wider public (Pathak and Eastaff, Reference Pathak, Eastaff, Singh and Zommers2014). The agency employs domain experts specialized in hydrology and flood risk assessment to collect and disseminate accurate information, and, in collaboration with the Met Office, forms the Flood Forecasting Centre which produces the best-combined understanding of flood risk based on weather forecasts, flood forecasts, catchment conditions, and the operational status of flood defenses (Flood Forecasting Centre, 2017). They generate a daily flood risk forecast, assessing the likelihood of flooding 5 days into the future.

2.4.2. Flood warnings data

The EA Real Time flood-monitoring API (Environment Agency, 2021b) provides a listing of all current flood alerts and warnings with applicable flood areas as well as further meta information (e.g., severity and associated water bodies) and is updated every 15 minutes. Flood alerts and warnings refer to different warning stages: flood alerts express that flooding is possible and it is important to stay alert and vigilant, while flood warnings refer to situations when flooding is expected and immediate action is required to protect people and properties. Since 1996, the Environment Agency has been designated as the lead authority for issuing accurate, reliable, and timely flood warnings to both emergency responders and the wider public in the UK (Pathak and Eastaff, Reference Pathak, Eastaff, Singh and Zommers2014). The agency’s system offers an end-to-end approach, including live data acquisition, data quality control, post-event data collection, reporting, and archiving. EA’s early warning strategy integrates traditional methods, like using measured water levels as triggers, with advanced modeling and forecasting, including relatively simple techniques like correlating peak levels/flows across sites as well as linked rainfall-runoff models with hydrological channel routing. Probabilistic and deterministic weather forecasts from the Met Office automatically feed into flood forecasting and warning processes, while measured rainfall intensities are used for real-time validation purposes (Pathak and Eastaff, Reference Pathak, Eastaff, Singh and Zommers2014). The performance of flood forecast models is evaluated regularly and continuous model recalibration cycles based on validation datasets from a series of past flood events ensure current, meaningful, and accurate flood forecasts. While the exact methodology remains undisclosed, in part due to the exclusive access to more detailed data granted to emergency responders, the public warnings data provided is highly trusted by authorities and public services (Met Office and Environment Agency, 2022) as well as academia, both as data source (Barker and Macleod, Reference Barker and Macleod2019; Wolf et al., Reference Wolf, Dawson, Mills, Blythe and Morley2022) and benchmark (Smith et al., Reference Smith, Hughes, Beven, Cross, Tych, Coulson and Blair2009). As the focus of our work lies on the methodology of integrating flood-related data from various domains and sources, the interested reader is referred to Pathak and Eastaff (Reference Pathak, Eastaff, Singh and Zommers2014) for more details about models as well as validation and data workflows deployed by the Environment Agency.

2.4.3. Building data

The Ordnance Survey (OS), as the national mapping agency of Great Britain, provides several open (e.g., OpenMap Local) and premium (i.e., Building Height Attribute) datasets describing the physical characteristics of the built environment in various levels of detail (Ordnance Survey, 2022). While the Building Height Attribute (BHA) data represents the most granular data about individual buildings, including their base polygon, building height, and ground elevation, the OpenMap Local contains building data on a more aggregated level and lacks information about building heights. Premium datasets are generally license-restricted; however, made available via Digimap (EDINA Digimap Ordnance Survey Service, 2022) for educational and research purposes. The Unique Property Reference Number (UPRN), which constitutes a unique and officially maintained identifier assigned to every addressable location in the UK, can be used to cross-links building information across datasets. The Department for Levelling Up, Housing & Communities offers open Energy Performance Certificate (EPC) data (Department for Levelling Up, Housing, and Communities, 2022) via three dedicated APIs for domestic, non-domestic, and display (i.e., mostly public buildings) certificates. This data contains property-level information about energy efficiency, key construction characteristics (i.e., number of rooms, total floor area, building type, etc.), high-level usage classification as well as address and location details, and is updated every 4–6 months. His Majesty’s Land Registry publishes several public datasets related to residential property sales on a monthly basis: The UK House Price Index (UKHPI) (HM Land Registry, 2022d) captures the monthly change in the value of residential properties on different levels of geospatial granularity. And the Price Paid Data (PPD) (HM Land Registry, 2022b) contains information about actual prices and dates of residential property sales, including address and property type.

2.4.4. Population data

The OpenPopGrid (Murdock et al., Reference Murdock, Harfoot, Martin, Cockings and Hill2015) provides an open-gridded population dataset for England and Wales based on the Office for National Statistics (ONS) 2011 Census as well as OS OpenData. It aims to enhance the spatial accuracy of the ONS population dataset by redistributing the population to actual residential areas.

2.5.1. Sensor and measurement ontologies

Several sensor ontologies have been proposed in the literature, each with its own design principles, coverage, and target applications: The Sensor, Observation, Sample, and Actuator (SOSA) ontology (Janowicz et al., Reference Janowicz, Haller, Cox, Le Phuoc and Lefrançois2019) provides a light-weight, modular, and self-contained core ontology for describing basic concepts related to sensors, observations, and actuators. While its simplicity compared to other ontologies fosters re-use, its limited coverage is not suitable for all sensor-related applications. The Semantic Sensor Network (SSN) ontology (World Wide Web Consortium, 2017) extends SOSA with more specialized and domain-specific concepts to provide a more expressive ontology to describe sensors and their observations, samples, and procedures used, observed properties, and actuators. While its comprehensive coverage of standardization is one of the key advantages, some aspects of the ontology may be overly complex for certain use cases. The Modular Environmental Monitoring (MEMOn) ontology (Masmoudi et al., Reference Masmoudi, Karray, Ben Abdallah Ben Lamine, Zghal and Archimede2020) defines a set of concepts and relationships for describing environmental monitoring equipment, including sensors, together with clear guidelines for mapping sensor data to the ontology. While MEMOn’s domain specificity ensures an accurate representation of environmental monitoring data, it may be overly specific for various applications. The Smart Appliances REFerence (SAREF) ontology (ETSI, 2020b) aims to provide a standardized framework for representing smart appliances and associated data and is designed in a modular fashion. Compared to SSN and SOSA, SAREF has a narrower scope, focusing specifically on smart appliances rather than sensors and observations more broadly; however, it can easily be extended.

Several ontologies have been proposed to describe environmental water resources and associated sensor readings; however, the focus has mainly been on either aligning heterogeneous data from various sensor web resources (Liu et al., Reference Liu, Bai, Kloppers, Fitch, Bai, Taylor, Fox, Zednik, Ding, Terhorst and McGuinness2012; Dutta and Morshed, Reference Dutta and Morshed2013; Wang et al., Reference Wang, Wei, Chen, He and Tian2020) or supporting water quality monitoring (Xiaomin et al., Reference Xiaomin, Jianjun, Xiaoci and Shaoli2016). A hydrological sensor web ontology-based on the SSN ontology has been developed to align semantics and support collaboration between individual water-related sensor networks (Wang et al., Reference Wang, Chen, Wang and Chen2018), primarily in response to natural disasters such as floods. It introduces hydrological domain classes and establishes relevant reasoning rules.

2.5.2. Flood ontologies

Various ontologies have been proposed for natural disaster management in general (Klien et al., Reference Klien, Lutz and Kuhn2006; Kollarits et al., Reference Kollarits, Wergles, Siegel, Liehr, Kreuzer, Torsoni, Sulzenbacher, Papez, Mayer, Plank, Maurer, Cimarosto and Bukta2009) as well as flooding in particular (Wrachien et al., Reference Wrachien, Garrido, Mambretti, Requena, Proverbs, Mambretti, Brebbia and Wrachien2012; Agresta et al., Reference Agresta, Fattoruso, Pasanisi, Tebano, De Vito, Di Francia, Murgante, Misra, Rocha, Torre, Rocha, Falcão, Taniar, Apduhan and Gervasi2014; Khantong et al., Reference Khantong, Sharif and Mahmood2020; Mughal et al., Reference Mughal, Shaikh, Wagan, Khand and Hassan2021). Recent systematic reviews of existing flood ontologies confirm the increasing usage of ontological approaches for flood knowledge and disaster management (Sinha and Dutta, Reference Sinha and Dutta2020; Mughal et al., Reference Mughal, Shaikh, Wagan, Khand and Hassan2021). Ontologies have been developed for different aspects and types of flood disasters, including urban flooding, flood risk and environmental assessment, and stakeholder and response management. The majority of the 14 flood ontologies reviewed by Sinha and Dutta (Reference Sinha and Dutta2020) are formal application ontologies built around small tasks performed during the response phase of flood disasters (Sinha and Dutta, Reference Sinha and Dutta2020). Among these, very few intend to conceptualize the broader domain knowledge of flood disasters, but are mostly scenario and/or task-specific. The number of classes varies significantly between 4 and 410; however, most of the ontologies are modular to simplify the complexity of conceptualizing large-scale spatiotemporal systems, such as floods (Sinha and Dutta, Reference Sinha and Dutta2020; Mughal et al., Reference Mughal, Shaikh, Wagan, Khand and Hassan2021). The study reveals that there is no standard flood ontology available in the field. The most commonly re-used ontologies comprise the Semantic Web for Earth and Environmental Terminology (SWEET) ontologies (Buttigieg et al., Reference Buttigieg, Mungall, Rueda, McGibbney, Cox, Duerr, Fils, Graybeal, Huffer, Narock, Ramachandran, Soiland-Reyes and Whitehead2018) and the MONITOR risk management ontology (Kollarits et al., Reference Kollarits, Wergles, Siegel, Liehr, Kreuzer, Torsoni, Sulzenbacher, Papez, Mayer, Plank, Maurer, Cimarosto and Bukta2009).

SWEET ontologies define a hierarchy of many flood risk-related terms and are often referenced for a variety of environmental concepts (Buttigieg et al., Reference Buttigieg, Mungall, Rueda, McGibbney, Cox, Duerr, Fils, Graybeal, Huffer, Narock, Ramachandran, Soiland-Reyes and Whitehead2018). The Environmental Ontology (ENVO) is a domain ontology describing various environment types across several levels of granularity. Its environmental hazard module contains suitable concepts to represent a single flood and flooding in general, including more detailed descriptions of typical kinds of flooding; however, no concepts to describe the social or economic damage of floods are considered. Several domain ontologies have been proposed to resolve ambiguity in information exchange and enable seamless collaboration between various stakeholders during flood disaster management (Khantong et al., Reference Khantong, Sharif and Mahmood2020; Mughal et al., Reference Mughal, Shaikh, Wagan, Khand and Hassan2021). The focus of these ontologies is mainly on conceptualizing the structure and sequence of relevant information, involved organizations, roles as well as the interplay between them rather than representing the actual data itself. Kollarits et al. (Reference Kollarits, Wergles, Siegel, Liehr, Kreuzer, Torsoni, Sulzenbacher, Papez, Mayer, Plank, Maurer, Cimarosto and Bukta2009) have developed MONITOR as formalized knowledge model to describe the relations between natural, social, and built environments, potentially hazardous events, and several risk assessment and management terms. The proposed risk model has been refined by Scheuer et al. (Reference Scheuer, Haase and Meyer2013) proposing a tailored ontology for multi-criteria flood risk assessment.

Although most of the proposed ontologies are claimed to be available in OWL, only ENVO could be found in coded form online. This matches previous findings by Sinha and Dutta (Reference Sinha and Dutta2020), which significantly hinders the re-usability of previous efforts and partially undermines the fundamental idea of common ontologies to enable machine-interpretability.

2.5.3. Building ontologies

OntoCityGML has been proposed as a comprehensive ontology (Chadzynski et al., Reference Chadzynski, Krdzavac, Farazi, Lim, Li, Grisiute, Herthogs, von Richthofen, Cairns and Kraft2021) for three-dimensional geometrical city objects based on the CityGML 2.0 standard (Gröger et al., Reference Gröger, Kolbe, Nagel and Häfele2012). CityGML is an open data model and XML-based format developed by OGC to describe urban environments by providing a common definition of the basic entities, attributes, and relations within a 3D city model. OntoCityGML provides a multi-scale model with five consecutive Levels of Detail (LoD), where the geometric representation of any building is successively refined from LoD0 to LoD4. A single building can have multiple spatial representations in different LoDs at the same time, for example, a simple 2D footprint polygon as LoD0 and a set of 3D surfaces confining the building volume as LoD1 representation. OntoCityGML primarily focuses on the geospatial representation of buildings to support spatial analyses and city planning. Further information about a building (e.g., building usage, year of construction, energy rating) can be encoded using predefined code lists or so-called genericAttributes. Although this approach provides further information about a building, it does not fulfill the requirements for semantically Linked Data.

A review of 40 metadata schemas for different phases of the building life cycle is provided by Pritoni et al. (Reference Pritoni, Paine, Fierro, Mosiman, Poplawski, Saha, Bender and Granderson2021). Five popular ontologies/schemas have been scrutinized in detail with regards to suitability and potential gaps in building modeling, namely the Brick Schema (2022), the BOT ontology (Rasmussen et al., Reference Rasmussen, Pauwels, Lefrançois, Schneider, Hviid and Karlshøj2021), the RealEstateCore ontology (RealEstateCore Consortium, 2020), SAREF including extensions (ETSI, 2020a) as well as SSN/SOSA (World Wide Web Consortium, 2017; Janowicz et al., Reference Janowicz, Haller, Cox, Le Phuoc and Lefrançois2019). The ontologies differ in perspective of how they represent building information, from focus on topologies of buildings and their sub-components (BOT) to sensors (SSN/SOSA) or devices (SAREF) and assets (Brick Schema). General-purpose ontologies such as BOT, SSN/SOSA, and the core of SAREF tend to leave gaps that require a modeler to supplement them with extensions or external schemas. Conversely, application ontologies like Brick, RealEstateCore, and SAREF4BLDG may not be as broadly applicable but offer domain-specific features. While the Brick Schema seems most suited for large, complex building automation, the Haystack ontology suits smaller-scale systems. Key ontologies are briefly discussed in Supplementary Material SI.6.3, and the interested reader is referred to Pritoni et al. (Reference Pritoni, Paine, Fierro, Mosiman, Poplawski, Saha, Bender and Granderson2021) for more details.

Despite the fact that the proposed ontologies differ in how exactly they represent building sub-components and their relationships, most of them are extensible and compatible with one another. Further perspectives on buildings are provided by specific domain ontologies, such as the iCity Building ontology (Katsumi, Reference Katsumi2021) providing a foundational vocabulary to represent building-related data within the urban context or the Domain Analysis-Based Global Energy Ontology (DABGEO) (Cuenca et al., Reference Cuenca, Larrinaga and Curry2020) fostering interoperability across the energy domain, with a focus on smart home and smart city energy management (Cuenca et al., Reference Cuenca, Larrinaga and Curry2020). The DABGEO ontology (Cuenca and Larrinaga, Reference Cuenca and Larrinaga2019) contains a tailored sub-module for knowledge about infrastructure and buildings, containing classes, properties, and axioms to represent static building features (e.g., surface, material), geometrical details (rooms, floors) as well as internal and external environmental conditions (e.g., room temperature).

3.2.1. Geospatial and time series representation

The following approaches are used to overcome limitations in representing geospatial and time series data (see Section 2.6):

To avoid using custom-typed Literals to encode geospatial coordinates suitable for Blazegraph’s geospatial engine (as done in previous studies: Chadzynski et al., Reference Chadzynski, Krdzavac, Farazi, Lim, Li, Grisiute, Herthogs, von Richthofen, Cairns and Kraft2021; Akroyd et al., Reference Akroyd, Harper, Soutar, Farazi, Bhave, Mosbach and Kraft2022), OBDA via Ontop (Xiao et al., Reference Xiao, Lanti, Kontchakov, Komla-Ebri, Güzel-Kalaycı, Ding, Corman, Cogrel, Calvanese, Botoeva, Pan, Tamma, d’Amato, Janowicz, Fu, Polleres, Seneviratne and Kagal2020) is used with the actual geospatial information being stored in a PostGIS database. PostGIS is an open-source spatial database extender for PostgreSQL, enabling the storage and retrieval of geospatial data. It adds support for geographic objects and geospatial functions, making it a powerful tool for managing spatial information within a relational database. Ontop, on the other hand, is a semantic data virtualization system that allows users to query relational databases via SPARQL as if they were triple stores. It “hides” the actual data source and exposes the data in terms of the mapped ontological concepts and relationships based on predefined mappings between SQL column and ontology concept names. Ontop facilitates the transformation of relational data into a semantic representation, promoting interoperability and advanced querying capabilities. Although Ontop is not fully compliant with OGC GeoSPARQL 1.0, it supports the main geospatial properties and functions. Hence, geospatial information can be served as virtual triples according to provided OBDA mappings and combined with actually instantiated data in Blazegraph.

To overcome issues with instantiating myriad individual time stamps, a light-weight time series ontology (Lee et al., Reference Lee, Hofmeister, Mosbach and Tsai2021) has been developed together with a dedicated TimeSeriesClient: upon creation, each time series gets instantiated within the KG with full semantic markup, while the actual tabular data (i.e., time stamp and data value) get stored in an associated relational database (e.g., PostgreSQL). The client provides a robust mapping between any data instance in the KG and the respective values stored in the relational database. Adding or deleting time series data only adds or deletes data points in the database, while deleting an entire time series via the TimeSeriesClient also deletes all associated relationships from the KG.

3.2.2. Environmental Measurement Station ontology

Several sensor ontologies have been proposed in the literature (see Section 2.5.1); however, most of them focus on detailed representations of measurement devices and procedures together with actual measurement values. In contrast, the Environmental Measurement Station ontology (OntoEMS) aims to establish an aligned conceptualization for environmental measurement observations from a variety of sources. OntoEMS disregards a comprehensive sensor and procedure representation, as such information is mainly unavailable from public APIs (such as the Met Office DataPoint, EA Real Time flood-monitoring API, or UK-AIR), and focuses on the nature of reported quantities, their geo-location, and time series data for historical readings and forecasts. It represents a light-weight top-level ontology designed to accommodate various data sources without imposing strict limitations on the required data coverage, while still providing an appropriate semantic representation of measured quantities. Given its modular design, OntoEMS can easily be extended with more detailed domain knowledge.

As depicted in Figure 4, the central concept is a ReportingStation, which represents any entity reporting environmental observations and/or forecasts. This general term is used because most of the screened data feeds from public APIs do not contain detailed information about the actual measurement devices. Instead, only high-level metadata regarding the location and nature of the supplied data is given, along with the actual readings data. A ReportingStation can refer to a physical asset that houses one or more actual sensors/measurement devices or a virtual station that provides certain readings. To enable geospatial capabilities using GeoSPARQL, each ReportingStation is defined as a rdfs:subClassOf a geo:Feature. All reported quantities are defined as a rdfs:subClassOf a om:Quantity and time series data are represented using the Time Series ontology (Lee et al., Reference Lee, Hofmeister, Mosbach and Tsai2021). Figure 5 illustrates this definition for WaterLevel and Rainfall measurements, which are declared as subclasses of om:Height, which itself is a subclass of om:Quantity. References to equivalent external concepts are captured using owl:equivalentClass or rdfs:subClassOf relationships, depending on the actual definition of the concept.

Figure 4. OntoEMS top-level ontology. OntoEMS represents the top-level ontology to represent environmental reporting stations (e.g., measurement stations) and associated readings of environmental observations (including time series values). Further domain knowledge can be incorporated with domain ontologies enriching ontoems:ReportingStation, om:Quantity, and om:Measure. All referenced namespaces are declared in Appendix A.1, with missing explicit namespace declarations referring to ontoems. Newly introduced concepts and relationships are depicted in red, while re-used ones are shown in black.

Figure 5. Example definition of a reported quantity. OntoEMS design requires reported quantities to be subclasses of om:Quantity; exemplarily depicted for rainfall and river level measurements, including references to further ontologies to leverage the power of Linked Data.

The OntoEMS top-level ontology can easily be refined to provide a more detailed description of specific domains, as illustrated in Figure 6 for water-level reporting stations. In this case, a WaterLevelReportingStation subclass is introduced to include additional information about attached water bodies, such as the catchment or river name, as well as the relative location to other stations along the same river (i.e., up- and downstream stations). A Range and Trend concept are included to provide additional context for current water level measurements. Such domain-specific extensions facilitate the direct import of application-specific ontologies, such as the RDF data model utilized by the EA Real Time flood-monitoring API (Environment Agency, 2021b). Furthermore, additional ABox level assertions can be incorporated, for example, to link instantiated air pollutants with equivalent instances in the European General Multilingual Environmental Thesaurus (GEMET) (European Environment Information and Observation Network, 2021) using owl:sameAs relationships.

Figure 6. Example OntoEMS domain ontology extension. The OntoEMS top-level ontology can be refined to suit needs for more detailed domain representations by elaborating ontoems:ReportingStation, om:Quantity, and om:Measure; exemplarily shown for water-level reporting stations monitoring the water level in rivers. All referenced namespaces are declared in Appendix A.1, with missing explicit namespace declarations referring to ontoems. Newly introduced concepts and relationships are depicted in red, while re-used ones are shown in black.

Several amendments to the Ontology of units of measure have been proposed (i.e., the inclusion of new quantities and corresponding units), which are currently being tracked in a fork of the official ontology. It is intended that these amendments will be submitted as a pull request in the future.

3.2.3. Flood Risk ontology

The aim of the proposed Flood Risk ontology (OntoFlood) is twofold: (1) to provide a reasonably general conceptualization of the flood risk domain, while (2) providing a suitable description for the available flood warning and forecast data provided by the EA Real Time flood-monitoring and Flood Forecast APIs (Environment Agency, 2021b; Flood Forecasting Centre, 2017). Compared to many previous ontology efforts, the focus is less on establishing a full-fledged conceptual representation of the entire domain and more on providing a semantic description of relevant phenomenological data to instantiate and operationalize actual data feeds. The majority of previously identified ontologies (see Section 2.5.2) is not publicly available and direct re-use of core concepts and relations is not possible. Hence, the majority of required concepts and relationships is created independently in OntoFlood and links to previously published ontologies are only included for a few classes where useful to enrich the semantic meaning (i.e., ENVO (Buttigieg et al., Reference Buttigieg, Pafilis, Lewis, Schildhauer, Walls and Mungall2016), SWEET (Buttigieg et al., Reference Buttigieg, Mungall, Rueda, McGibbney, Cox, Duerr, Fils, Graybeal, Huffer, Narock, Ramachandran, Soiland-Reyes and Whitehead2018)). Nevertheless, key design choices in OntoFlood are based on previous conceptualizations to build on existing domain knowledge. Several concepts are borrowed directly from the data model used by the EA Real Time flood-monitoring API (Environment Agency, 2021b) (prefixed with rt). Compared to previous flood ontologies, the proposed ontology represents the areal extent of a flood by any arbitrarily shaped polygon instead of linking a flood to a particular predefined region or district. This allows for more versatile geospatial representation, similar to the flood hazard map concepts developed by Scheuer et al. (Reference Scheuer, Haase and Meyer2013). However, the primary purpose is an accurate assessment of affected buildings and people using geospatial queries, as compared to pure visualization purposes.

Figure 7. OntoFlood ontology (extract only). The OntoFlood ontology describes flood events and their (potential) impacts in three stages: (1) actual flood events, (2) flood warnings, and (3) forecasted floods. The ontology has been designed to represent available data from the Environment Agency Real Time flood-monitoring API (Environment Agency, 2021b) and assess built infrastructure as well as population at risk. All referenced namespaces are declared in Appendix A.1, with missing explicit namespace declarations referring to ontoflood.

OntoFlood is capable of describing floods and associated impacts in three different stages: actual flooding events, flood alerts and warnings (i.e., expected flooding events), and flood forecasts (i.e., potential flooding events, but less certain). The core concept to describe a flood is the envo:flood class, which is defined as a rdfs:subClassOf of soph:Event. Each event is associated with a certain time interval and a Location which provides information about the parent AdministrativeDistrict as well as the actual ArealExtentPolygon of the flood. The ArealExtentPolygon is defined as subclass of a geo:Feature and the encompassing AdministrativeDistrict shall either be the corresponding IRI from ONS Geography Linked Data (Office for National Statistics, 2022) or refer to it via an owl:sameAs relationship. This enables geospatial capabilities, such as the identification of certain geo:Features within a flood polygon or insights into most relevant flood areas in a particular county. An event can resultIn a monetary Impact (positive or negative) describing the total monetary consequences of its occurrence. In the case of flooding, this value describes the total (potential) damage to all affected infrastructure assets. More detailed insights into the (potential) effects of a envo:flood are represented using the affects relationship, connecting to Population and infrastructure assets, such as Buildings, representing both the count and estimated monetary value.

The rt:FloodAlertOrWarning is the key concept for the flood warnings and alert stage, which represents the key data provided by the flood-monitoring API (Environment Agency, 2021b). Each alert or warning warnsAbout a potential envo:flood event and is associated with a certain Severity and rt:FloodArea. Required levels of severity are defined and instantiated as ABox together with the Tbox of the ontology. The concept of a FloodAlertOrWarningHistory is introduced to store key information (i.e., date of issue/change, severity, impacts) of previously issued flood alerts and warnings for a particular rt:FloodArea. This allows us to investigate potential trends in both frequency and severity of flood warnings for a certain area and tailor efforts where to take preventive measures. The flood forecast stage is centered around the FloodForecast concept, which predicts a potential envo:flood event. As a flood forecast is less certain and, hence, less quantitative than a rt:FloodAlertOrWarning, it is mainly characterized by its RiskLevel expressing a hazard potential defined by expected likelihood and impact.

3.2.4. Building Environment ontology

The Building Environment ontology (OntoBuiltEnv) aims to create a lightweight ontology to represent properties (i.e., buildings and flats) suitable for a variety of use cases within TWA. It is designed to integrate with existing agents and knowledge representations, such as OntoCityGML and the City Energy Analyst (CEA) Agent (Chadzynski et al., Reference Chadzynski, Li, Grisiute, Chua, Hofmeister, Yan, Tai, Lloyd, Tsai, Agarwal, Akroyd, Herthogs and Kraft2023a). Compatibility and interoperability with previous building instantiations based on OntoCityGML is ensured by introducing a link between corresponding building instances across both ontologies. While OntoCityGML represents all geospatial and geometric aspects of a building (i.e., in various LoDs), OntoBuiltEnv provides a semantic representation of additional building information (i.e., to replace previously used non-semantic ExternalReference and genericAttribute). The ontology is designed to represent publicly available building data based on the Energy Performance Certificate and HM Land Registry APIs (Department for Levelling Up, Housing, and Communities, 2022; HM Land Registry, 2022c) and follows a use case specific approach, considering only a required subset of all available data for now, that is, focusing on key construction properties as well as property market value relevant information. However, the design ensures extensibility to accommodate additional use cases in the future and already captures building usage as well as solar photovoltaic descriptions to support ongoing efforts to refine the CEA agent.

The ontology reuses existing concepts from multiple screened ontologies (see Section 2.5.3), such as DABGEO or iCity Building (Cuenca and Larrinaga, Reference Cuenca and Larrinaga2019; Katsumi, Reference Katsumi2021). A few public concepts from the custom HM Land Registry data model (HM Land Registry, 2022b) are included to represent property market data (prefixed with lrppi). A Property represents the central concept of the ontology, with dabgeo:Building and Flat as relevant subclasses. While each Property holds multiple relationships regarding its location, construction characteristics, and market valuation details, certain information is restricted to buildings only, for example, elevation and roof area specifications (see Figure 8). The dabgeo:Building class is the key concept to represent buildings and the hasOntoCityGMLRepresentation relationship connects it with an external IRI representing the corresponding OntoCityGML instance containing all geospatial information. To enrich semantics, owl:equivalentClass relationships are included to refer to building definitions in further ontologies. This ensures linking and easier integration of potentially more elaborate building models in the future (e.g., BIM representation). All buildings are again represented as geo:Feature to enable geospatial capabilities using GeoSPARQL (e.g., to assess whether a building is located within a particular flood polygon). Each property is connected with an icontact:Address containing detailed address information, including owl:sameAs links to corresponding statistical ONS geography IRIs for instantiated PostalCodes and AdministrativeDistricts to enable further navigation and geospatial analyses.

Figure 8. OntoBuiltEnv ontology part 1 (extract only). The OntoBuiltEnv ontology provides a semantic description for properties (i.e., both buildings and flats), including location and address details as well as information about previous sales transactions and current market value estimates. The ontology has been designed to represent available data from both Energy Performance Certificates (Department for Levelling Up, Housing, and Communities, 2022) and His Majesty’s Land Registry (HM Land Registry, 2022a), while seamlessly integrating with OntoCityGML (Centre Universitaire d’Informatique at University of Geneva, 2012) for the geospatial representation of buildings. All referenced namespaces are declared in Appendix A.1, with missing explicit namespace declarations referring to ontobuiltenv.

Figure 9 illustrates the current representation of PropertyUsage types, which has been aligned between available data from the API and requirements from the CEA agent. Furthermore, several subclasses have been introduced to formalize relevant property types (e.g., maisonette or house), built forms (e.g., terraced or detached), and key construction components. The hasIdentifier relationship is used to provide a unique identifier for each instantiated building, required for external referencing or instance matching. In UK context this corresponds to the UPRN of the property, which can be used to unambiguously identify each property and potentially assimilate further data in the future. The hasLatestEPC refers to the identifier of the underlying energy performance assessment of the instantiated data and can be used to assess whether this data still reflects latest information available from the API.

Figure 9. OntoBuiltEnv ontology part 2 (extract only). The OntoBuiltEnv ontology provides relevant concepts to represent properties, including their usage classification, major construction components, property type and built form, and energetic characteristics.

3.3.1. Met Office Agent

The Met Office Agent recurringly queries the Met Office DataPoint API (Met Office, 2022) for latest weather observation and forecast data and instantiates it according to the OntoEMS ontology. This agent also serves as template for other OntoEMS input agents to keep TWA in sync with the real world. A detailed Unified Modeling Language (UML) diagram is provided in Figure 12. The agent offers dedicated endpoints to update (1) instantiated reporting stations, (2) reported quantities (i.e., measured and/or forecasted parameters), and (3) the actual time series data of those quantities. Additionally, an endpoint to update all instantiated information is provided, performing tasks 1–3 sequentially: Upon invocation (either via HTTP request or scheduled background task), the agent queries all available reporting stations from both the API and TWA. In case stations are available from the API, but not TWA, they get instantiated. Subsequently, all available stations and their associated readings are queried from both the API and TWA. Similarly, potentially missing quantities are instantiated and the associated time series instances to store actual readings get initialized. Lastly, the latest time series data are queried from the API for all instantiated quantities and added to the respective TimeSeries instances. Potentially, duplicated timestamps are overwritten to ensure that latest information is available from TWA at all times.

Figure 12. Met Office Agent. The Met Office Agent recurringly queries the Met Office DataPoint API (Met Office, 2022) for both latest weather observation and forecast data and instantiates it according to the OntoEMS ontology. This agent also serves as template for other OntoEMS input agents to keep TWA in sync with the physical world.

3.3.2. Air Quality Agent

The Air Quality Agent recurringly queries air pollutant concentration data from the UK-AIR Sensor Observation Service (Department for Environment, Food, and Rural Affairs, 2023) and instantiates it according to the OntoEMS ontology. It follows the same implementation approach as the Met Office Agent, with consecutive updates of reporting stations, measured quantities, and actual time series data. Similarly, only not yet instantiated stations and readings are added to the KG on subsequent agent invocations. To leverage the power of Linked Data, each unambiguously identifiable air pollutant reading is linked to its equivalent concepts of the European air quality e-Reporting initiative (European Environment Information and Observation Network, 2021) via an owl:sameAs relationship. This provides additional information about relevant protection targets, (commonly used) units, and measurement equipment, besides further metadata. Moreover, this eases alignment and interoperability with other data sources and stations potentially to be incorporated later.

3.3.3. River Level Agent

The River Level Agent retrieves sensor observation data from the EA flood-monitoring API (Environment Agency, 2021b) and instantiates it according to the OntoEMS ontology. It downloads all available data in RDF format once per day and updates the KG by assimilating new station and readings information as well as adding new time series data. The agent instantiates all provided readings, not just river levels, including water flow rates, rainfall, and wind measurements. For WaterLevelReportingStations at rivers the agent enriches the RDF data with additional information about stage scales, such as the reference datum and typical low/high readings, and adds relationships to potential downstream stations. Data about the relative location of stations is obtained from another government service (Met Office and Environment Agency, 2022) through web scraping. The agent also derives and instantiates the current Range and Trend for each WaterLevelReportingStation with associated stage scale instance. The Range is determined by comparing the latest water level reading with typical low and high readings, while the Trend is based on an assessment of the readings over the last 12 hours. A rising or falling Trend is instantiated if the difference between the last and first value in that period exceeds $ \pm $ 10%, respectively.

3.3.4. Building Importer Agent

The Building Importer Agent imports entire CityGML files and instantiates respective buildings according to the OntoCityGML ontology (Chadzynski et al., Reference Chadzynski, Li, Grisiute, Chua, Hofmeister, Yan, Tai, Lloyd, Tsai, Agarwal, Akroyd, Herthogs and Kraft2023a, Reference Chadzynski, Silvennoinen, Grisiute, Farazi, Mosbach, Raubal, Herthogs and Kraft2023b). The agent supports building representations in multiple LoDs; however, given the available data from OS, this work relies on building instantiations in LoD1, with buildings represented as simple block models describing their overall shape and layout (i.e., building footprints as polygon). Additional building data, such as building height or associated postcode, are also instantiated according to OntoCityGML, either as dedicated data property (e.g., building height) or as genericAttribute (e.g., postcode).

3.3.5. Thematic Surface Discovery Agent

The Thematic Surface Discovery (TSD) Agent enhances instantiated OntoCityGML LoD1 building representations to LoD2 (Chadzynski et al., Reference Chadzynski, Li, Grisiute, Chua, Hofmeister, Yan, Tai, Lloyd, Tsai, Agarwal, Akroyd, Herthogs and Kraft2023a). The agent identifies wall, roof, and ground polygons and adds explicit semantic annotations to complement their pure geometrical perspective in an OntoCityGML compliant form. The agent also offers an endpoint to only identify and restructure the ground surface, that is, footprint, of a building. As this work focuses on LoD1 building representations, most of the thematic surface restructuring is not necessary; however, the ground surface classification is a prerequisite for the instantiation of UPRN information by the UPRN Agent.

3.3.6. Unique Property Reference Number Agent

The Unique Property Reference Number (UPRN) Agent enriches instantiated OntoCityGML building instances with a unique identifier, that is, their UPRN given the UK context of this work. Depending on the provided HTTP request parameters, the agent processes individual buildings (i.e., single OntoCityGML city object with provided IRI) or targets all buildings instantiated in a provided triple store namespace. For each target building, the agent queries the OS Features API (Ordnance Survey, 2022) with the building’s bounding box to retrieve all enclosed UPRNs. Subsequently, all returned UPRNs are tested against the ground surface to exclude UPRNs not intersecting the building itself. Only intersecting UPRNs are then instantiated and linked to the respective building(s).

3.3.7. Energy Performance Certificate Agent

The Energy Performance Certificate (EPC) Agent retrieves data from all three EPC APIs (Department for Levelling Up, Housing, and Communities, 2022) (i.e., domestic, non-domestic, and display certificates) and instantiates relevant building data according to the OntoBuiltEnv ontology. To manage the size of individual API requests, the data is queried per postcode and for all three APIs subsequently. To instantiate all postcodes for a particular local authority, an initial request must be sent to the agent. New postcodes are only instantiated if the local authority is not already present in TWA. All instantiated postcodes get linked to corresponding ONS IRIs using the owl:sameAs relationship. A detailed UML diagram is provided in Supplementary Material SI.1, with key agent logic described below:

The agent requires an available SPARQL endpoint to retrieve instantiated OntoCityGML buildings, since EPC data is only assimilated for properties with available geospatial representation. Initially, all instantiated postcodes are queried from TWA, and the latest EPC data for all instantiated postcodes are retrieved from the respective API endpoint. Returned EPC data with a corresponding UPRN instantiated in OntoCityGML gets instantiated according to the OntoBuiltEnv ontology: either as standalone building or as property belonging to a parent building if the associated OntoCityGML building contains multiple UPRNs. Only outdated EPC data is instantiated, while already instantiated data are skipped. The agent determines information for parent buildings by aggregating data of contained child properties: by summing up actual values (e.g., number of rooms and floor area), using the most common value (e.g., EPC rating code, property type), or concatenating distinct values of child properties (e.g., property usage, description of construction components). After ingesting new information and to ensure that updated information is detectable by the DIF, the IRIs of all (potential) pure inputs managed by the EPC Agent (i.e., Property, PostalCode, and FloorArea instances) are retrieved and associated timestamps are added or updated.

To enable visualization using TWA’s unified visualization interface, the geospatial representation of all buildings (i.e., their 2D footprints and elevations) must be uploaded to PostGIS. The agent provides all necessary functionality to do so; however, corresponding building instances in OntoBuiltEnv and OntoCityGML need to be matched beforehand using the Building Matching Agent.

3.3.8. Building Matching Agent

The Building Matching Agent links buildings instantiated according to OntoBuiltEnv with their OntoCityGML equivalents. While OntoBuiltEnv provides the overall semantic description of properties, OntoCityGML is solely used for the geospatial representation of buildings. Linking corresponding instances allows the combination of both of these complementary perspectives. Matching is conducted using UPRNs as unique identifiers and realized by instantiating one additional relationship between matched IRIs, namely hasOntoCityGMLRepresentation. For details please refer to Supplementary Material SI.1.

3.3.9. Property Sales Agent

The Property Sales Agent is an input agent which queries HM Land Registry Open Data and instantiates it according to the OntoBuiltEnv ontology. More precisely, it queries latest property sales transactions and price index data from the Price Paid (HM Land Registry, 2022b) and the UK House Price Index Linked Data (HM Land Registry, 2022d), respectively, via the publicly available SPARQL endpoint (HM Land Registry, 2022c). After instantiating new property sales data, the agent also instantiates the relevant derivation markups to allow for the automatic assessment of the AveragePricePerSqm per PostalCode as well as the PropertyValueEstimation of individual buildings. A detailed UML diagram is provided in Supplementary Material SI.1, with key agent logic described below:

Initially, all instantiated properties are retrieved from TWA, including their full address information. Subsequently, for each postcode latest transaction records (i.e., latest transaction date and price paid) are retrieved for all unique addresses from Land Registry’s SPARQL endpoint. Since the PPD does not contain UPRN information, sales transactions are assimilated based on address matching. To attach a previous sales record to an instantiated property, both postcode and property type (i.e., building or flat) must match. However, to account for minor discrepancies between instantiated address information (i.e., based on EPC data) and addresses from HM Land Registry, fuzzy matching of the concatenated string of street name, street number, building name, and unit name is used. If the fuzzy match exceeds a minimum confidence score (i.e., 95) both addresses are considered equivalent and the retrieved TransactionRecord is instantiated for the respective property. The Python library Fuzzywuzzy (Cohen Reference Cohen2020) is used and two matching algorithms have been compared, that is, the Levenshtein distance and the Damerau-Levenshtein algorithm. Additionally, the performance of multiple scoring methods (i.e., simple ratio, partial ratio, token sort ratio, and token set ratio) has been investigated. The token set ratio calculates the similarity score based on the ratio of the length of the longest common sub-string to the total length of the two strings being compared after breaking them into individual words and accounting for differences in word order and word frequency. Manual comparisons of the matching results suggest that the Levenshtein distance with the token set ratio performs best. While the scoring method has a significant influence, the difference between both scoring algorithms is very minor.

Having assimilated all property sales transaction information, the PropertyPriceIndex (i.e., the UKHPI) is instantiated and/or updated for all instantiated administrative districts (i.e., local authorities, as they are the most granular regions for which the UKHPI is published). Finally, the agent also updates the timestamps of amended pure derivation inputs (i.e., TransactionRecord and PropertyPriceIndex instances) and instantiates/updates the required markups for both the AveragePricePerSqm and the PropertyValueEstimation derivation. Both of these derivations are initialized as synchronous derivations to compute and instantiate an initial evaluation immediately. As the PropertyValueEstimation depends on the AveragePricePerSqm, the latter one is marked up first to ensure availability of the required derivation input. Both markup methods are part of the Property Sales Agent and described in more detail in the following two paragraphs.

Average Square Meter Price Derivation Markup: This method creates the semantic markup required by the DIF to enable the automatic assessment of the AveragePricePerSqm for each instantiated PostalCode: for each instantiated PostalCode an OntoDerivation instance is initialized to be handled by the Average Square Meter Price Agent and connecting all input instances via an isDerivedFrom relationship. The method also handles postcodes without previous sales transaction records. In such cases, simply no transaction record instances get connected to the derivation instance as inputs, which ensures that the Average Square Meter Price Agent in turn queries data from nearby postcodes from the Land Registry SPARQL endpoint. A detailed UML diagram of the markup method is provided in Supplementary Material SI.1, with the key logic described below:

Initially, all unique PostalCodes are queried from TWA, followed by the retrieval of all associated TransactionRecords and the representative PropertyPriceIndex. If already instantiated (i.e., due to previous derivation computation), also the AveragePricePerSqm instance for the postcode is retrieved. If no AveragePricePerSqm instance exists yet, a synchronous derivation for new information is initialized to connect all TransactionRecords of that PostalCode as well as the associated PropertyPriceIndex with a newly instantiated derivation instance and get an initial assessment computed immediately by the Average Square Meter Price Agent. Additionally, not yet instantiated timestamps are added to all input instances. Otherwise, TransactionRecord instances not yet connected with the existing AveragePricePerSqm instance of the respective postcode (i.e., transaction record has been instantiated after previous average price assessment) are retrieved and added to the existing derivation instance. Finally, a derivation update is requested to ensure the instantiated AveragePricePerSqm is up-to-date.

Property Value Estimation Derivation Markup: Similar to the Average Square Meter Price Derivation Markup method, this method maintains the required derivation markup for the automatic assessment of the PropertyValueEstimation of instantiated buildings. A detailed UML diagram is provided in Supplementary Material SI.1, with the key logic described below:

Initially, all instantiated properties are retrieved, together with their associated sales TransactionRecord and FloorArea as well as representative PropertyPriceIndex and AveragePricePerSqm (if available). If already instantiated (i.e., due to previous derivation computation), also the current PropertyValueEstimation instance is queried. If no market value estimate exists yet for a building, a synchronous derivation for new information is initialized based on all available inputs for that building and requested for immediate initial assessment by the Property Value Estimation Agent. As the AveragePricePerSqm derivation is marked up first, its value should already be instantiated when conducting the property value estimation markup. In the unlikely event that this is not the case, the derivation can also be initialized with the AveragePricePerSqm derivation instance as input. In case a property already has an instantiated PropertyValueEstimation, the need for a potential update is evaluated: In case the instantiated property value isDerivedFrom the representative AveragePricePerSqm and the FloorArea, but a sales TransactionRecord is actually instantiated for the property (i.e., a new sales transaction has been made available in HM Land Registry after the last time the property value has been estimated), the respective TransactionRecord is added as additional input to the existing derivation and an update is requested to re-assess the current market value. Furthermore, not yet instantiated timestamps are added to all input instances.

3.3.10. Average Square Meter Price Agent

The Average Square Meter Price Agent is a derivation agent to estimate the average square meter price of properties on a postcode level. The required input data comprises total FloorArea and latest sales TransactionRecord for properties as well as the representative PropertyPriceIndex. A detailed UML diagram is provided in Supplementary Material SI.1, with key agent logic described below:

Upon invocation, the agent verifies whether received input instances are suitable to assess the AveragePricePerSqm, that is, both a PostalCode and PropertyPriceIndex are available (i.e., have been marked up properly). Subsequently, the number of TransactionRecords associated with the derivation instance (i.e., available for current postcode) is derived. The agent requires a minimum threshold of transaction instances to compute a meaningful average (e.g., minimum of five transactions). If less (or even no) transactions are available, data from nearby postcodes are included: the agent retrieves all postcodes within the same Super Output Area from ONS public SPARQL endpoint (Office for National Statistics, 2022), queries the instantiated number of transactions for each of them from TWA and orders the postcodes by increasing euclidean distance from current one. Lastly, the nearest postcodes required to fulfill the minimum number of transactions are extracted and all associated TransactionRecords are used in the assessment.

Having retrieved a sufficient set of TransactionRecords, each sales price is normalized with the total FloorArea of the property and scaled using the PropertyPriceIndex to derive today’s equivalent value for each historical transaction. Finally, the arithmetic mean is computed and instantiated as current AveragePricePerSqm for the respective PostalCode.

3.3.11. Property Value Estimation Agent

The Property Value Estimation Agent is a derivation agent to calculate the current market value estimate of properties instantiated in TWA. The estimated market value of any property can be determined by either (1) re-calibrating the latest available historical transaction price to today’s market conditions or (2) multiplying the total floor area of the property with a representative average square meter price. A detailed UML diagram is provided in Supplementary Material SI.1, with key agent logic described below:

Initially, the agent verifies that sufficient inputs are provided (i.e., have been marked up properly), meaning that either a historical TransactionRecord and PropertyPriceIndex or total FloorArea and AveragePricePerSqm instances are available. The first combination is prioritized as actual previous sales transactions for a certain property are considered better proxies for the current market value compared to the more general approach using an average square meter price. Hence, the latter set of inputs shall only be used as fall-back for properties without any previous sales information. After computing the PropertyValueEstimation based on available inputs, it is instantiated in TWA as derivation output according to OntoBuiltEnv.

Although significantly more elaborate methods exist to estimate property prices, that is, considering numerous influential factors, such as micro-location, building characteristics, usage classification, and so on, this simplified evaluation approach suffices for an initial proof-of-concept. Kept intentionally simplistic for this phase of our research, it will likely be subject to further refinement in future iterations.

3.3.12. Flood Warnings Agent

The Flood Warnings Agent is an input agent which queries flood alert and warning data from the EA Real Time flood-monitoring API (Environment Agency, 2021b) and instantiates it according to the OntoFlood ontology. For readability, both alerts and warnings are referred to as flood warnings in the following. A detailed UML diagram is provided in Figure 13, with the key agent logic described below:

Figure 13. Flood Warnings Agent. The Flood Warnings Agent recurringly (i.e., every hour) queries the EA Real Time flood-monitoring API (Environment Agency, 2021b) and instantiates current flood alerts and warnings. Newly raised alerts/warnings are instantiated (including the instantiation of associated flood area(s)) and already existing ones are updated. Ceased alerts/warnings are deleted from the KG, while associated areas are kept for future reference. Each instantiated alert or warning receives a derived information markup to connect its derivation instance with all relevant inputs for a flood impact assessment. This markup is either newly instantiated or updated (details in Figure 14). Exemplary pseudocode and SPARQL queries for the sections highlighted in red are provided in Supplementary Materials SI.2 and SI.3.

Initially, all instantiated FloodAlertOrWarnings are queried from TWA and matched against available, and hence currently active, ones from the API: (1) Whenever new flood warnings are issued by the API, the agent initially verifies whether the affected FloodArea has already been instantiated (i.e., as flood areas are frequently re-used by EA). If the FloodArea is already instantiated, the corresponding instance is retrieved. Otherwise, a new instance is created, including all meta information about geospatial extent, attached water body, and so forth. Subsequently, a new FloodAlertOrWarning is instantiated, containing all relevant details about severity, warning message as well as the relationship to the applicable FloodArea. (2) Existing but outdated FloodAlertOrWarnings get updated with latest API information on severity and message details; however, some information, such as the relations to associated FloodArea and Flood event IRI, are kept unaltered. (3) Any previously instantiated warnings that are no longer available from the API are archived. Archiving shall create a log of the flood warnings history for a particular FloodArea to allow for elaborate flood risk analyses; however, this feature is not yet fully implemented and obsolete FloodAlertOrWarning instances simply get deleted from TWA, together with all relationships, derivation markup, associated timestamps, and derivation outputs. However, derivation inputs and associated flood areas are not affected, as they may be associated with or re-used by other flood warnings.

After assimilating latest flood warnings, the agent also instantiates the relevant derivation markup and adds or updates associated input timestamps to allow for automatic impact (re-)assessment by the Flood Assessment Agent (details in paragraph below).

Flood Assessment Derivation Markup: This method is part of the Flood Warnings Agent and handles the required derivation markup for the automatic assessment of potential impacts associated with individual flood warnings. It creates and maintains an OntoDerivation instance for each FloodAlertOrWarning, adds all necessary information about the responsible derivation agent, and connects it with all actual input instances via an isDerivedFrom relationship. A detailed UML diagram of the markup method is provided in Figure 14, with the key logic described below:

Figure 14. Flood Assessment Derivation Markup. The Flood Assessment Derivation Markup is a method of the Flood Warnings Agent to connect instantiated flood alert/warning information with corresponding flood assessment derivations. Furthermore, all potentially affected buildings (i.e., buildings located within the flood area polygon) are determined and attached to the derivation instance. Those relationships are required to specify the input instances for each flood assessment and allow the Flood Assessment Agent (see Figure 15) to automatically detect any outdated information and trigger a re-evalution of potential impacts when they are accessed.

For newly instantiated FloodAlertOrWarnings, the agent retrieves a list of all Buildings within the flood area by using geospatial querying to assess which building footprints fall within the ArealExtentPolygon of the flood. Subsequently, for each of these buildings, the agent retrieves the instantiated PropertyValueEstimation instance if available. If not, it retrieves the corresponding derivation instance. Finally, an asynchronous derivation is instantiated to connect the flood assessment derivation instance with all potentially affected Building IRIs, their PropertyValueEstimation IRIs, and the respective FloodAlertOrWarning instance. Any potentially not yet instantiated timestamps for pure inputs are added, and an initial assessment is requested, which will be executed the next time the Flood Assessment Agent monitors the triple store.

For already instantiated but updated FloodAlertOrWarnings, the timestamp of the flood warning instance is updated and a derivation update for the existing derivation IRI is requested. As ceased flood warnings are deleted from TWA, including their derivation markup, no handling is required for lifted warnings.

3.3.13. Flood Assessment Agent

The Flood Assessment Agent is a derivation agent to estimate the number of people and buildings at risk of flooding as well as the total monetary value of the potentially affected building stock. The required input data for each flood assessment comprises a collection of Building and PropertyValueEstimation instances and the respective FloodAlertOrWarning instance itself. A detailed UML diagram is provided in Figure 15, with key agent logic described below:

Figure 15. Flood Assessment Agent. The Flood Assessment Agent uses the DIF to assess potential impacts of (anticipated) floods with regards to (1) number of people at risk, (2) number of buildings at risk, and (3) estimated building stock value at risk. The agent is implemented as asynchronous derivation agent which monitors the instantiated information within a specified triple store namespace at predefined frequency. Pure input instances required to evaluate the impacts of a flood warning are marked up as part of the instantiation of new flood alerts and warnings (see Figure 13). A more detailed pseudocode example for the section highlighted in red is provided in Supplementary Material SI.2.

Initially, the agent verifies whether the marked-up input instances are suitable to perform a flood impact assessment, that is, that exactly one FloodAlertOrWarning instance is provided and the set of PropertyValueEstimation instances does not exceed the number of related Building instances. Missing property value estimations for some buildings as well as completely absent building and value estimation inputs are allowed (i.e., however, would result in an impact assessment of zero).

Subsequently, the Severity of the FloodAlertOrWarning is retrieved. For inactive flood warnings, all potential impacts are set to zero. Otherwise, the impacts are assessed: (1) The number of people affected is determined by conducting a geospatial count over the population density raster data within the boundary of the ArealExtentPolygon associated with the FloodAlertOrWarning of interest. (2) The number of buildings at risk is assessed by summing up all Building IRIs that are marked up as potentially affected derivation inputs. And (3) the total monetary value at risk is estimated by retrieving and summing up the property market values from marked-up PropertyValueEstimation IRIs. Finally, all potential flood impacts are instantiated according to OntoFlood as derivation outputs. While this assessment logic is intentionally simplistic for this proof-of-concept and concentrates solely on tangible property loss when evaluating economic impact, it showcases the framework’s general capabilities for automated impact assessments; however, the technological capability behind the assessment is highly adaptable and supports future refinements as necessary.