dataesr/scientific-paragraphs-categorization huggingface dataset:
Both of these models have limitations and uncertainties in themselves, making a fine scale understanding of the limitations of the InVEST model challenging. In other words, differences in models observed in Figures  1  and 2  might also be due to errors in the reference data and future studies could examine the effect of uncertainty in reference datasets on calibration and model performance. LST datasets, on the other hand, are less prone to such limitations and are more robust when it comes to spatial distributions. Absolute values are nonetheless challenging to ascertain requiring correction algorithms. Finally, an important study limitation that could be explored in future work is the spatial resolution and scale of case studies. In both cases, the InVEST model was evaluated at 1-km horizontal resolution over an area of about 100 km by 100 km.
Acknowledgements This study is part of the  IDEFESE  project (https://idefese. wordpress. com/) funded by  ADEME , the  French Ministry for an Ecological Transition (CGDD and PUCA) , and  AgroParisTech. We wish to thank the  Institut Paris Region  for providing important data necessary for the success of the study. PH acknowledges additional funding from the  National Research Foundation, Prime Minister's Office, Singapore  under award  NRF-NRFF12-2020-0009.
Data availability The source files for the biophysical tables to run the InVEST models can be found in Supplementary Information. Other input data such as the LULC map for the Paris case study are not publicly available. https://doi. org/10. 5194/egusphere-2023-928 Preprint. Discussion started: 11 September 2023 c Author(s) 2023. CC BY 4. 0 License.
https://doi. org/10. 5194/egusphere-2023-928 Preprint. Discussion started: 11 September 2023 c Author(s) 2023. CC BY 4. 0 License. Overall, this discussion of data quality and calibrated parameter values highlights an important contribution of this study, in the customized calibration tool available on Github (https://github. com/martibosch/invest-ucm-calibration and on Zenodo, please refer to the Code Availability section). Such a tool can be applied to any other city where the InVEST Urban Cooling model is applied with the only data requirement, beyond the InVEST model input data, being a reference temperature dataset (either point data or raster). The calibration tool allows for systematic calibration and model testing, which paves the way for better understanding of model limitations and strengths.
Although in our case studies the performance improvement from calibration was modest, future work could assess the performance of the model over multiple cities with comparable datasets, examine the potential of local climate zones for improved parameterization, or explore finer temporal resolution by linking the night and day model outputs. 5 Conclusion In this study, we have developed a custom calibration tool to assess the performance of the InVEST Urban cooling model in two case studies: in Paris, France, and the Twin Cities, MN, USA. Our analyses expand on past model testing studies by providing a much more extensive validation dataset of air temperatures (continuous data based on a reference urban climate model in Paris, and on data interpolated from a dense weather station network in the Twin Cities).
The ease of implementation is another significant advantage of the proposed methodology, as demonstrated through the utilization of Python to implement the entire approach, enabling practitioners to readily incorporate it into existing systems and workflows. Furthermore, the proposed iterative solution injection approach allows the system to continuously analyse historical data and suggest optimizations at the main model level. By learning from past experiences and adapting to new circumstances, the system can continually enhance its performance. This opens up possibilities for future studies in artificial intelligence, where historical databases can be leveraged to further refine and improve the design of the model. The remainder of this paper is organized as follows: Section 2 presents a comprehensive review of the related work, Section 3 provides a comprehensive overview of the materials and methods employed in this study.
Russel et al. [41]  classified different types of exceptions that may arise during the execution of a process and suggested techniques to manage them. Similarly, Adams et al. [42]  maintained a database of exception handling procedures known as exlets to deal with predefined categories of exceptions. The database may be built during the design stage or dynamically during runtime. In a recent study, Jasinski et al. [43]  presented a workflow management system that controls the environment using dynamically generated workflows. Exception detection and handling in the process creation provides solutions for possible occurrences. This approach enables rapid development of new tasks, known or unknown, and assesses the quality of the recommendations created through feedback from the managed environment.
Taken a step further by Kerstin et al. [44] , they introduced an additional layer of fragments that can be reused in workflows in case of failure. However, one notable drawback of USM approaches is their limited scope when it comes to repairs. These approaches typically focus on addressing issues within a specific area, and the solutions available are often pre-defined and stored in databases. If a malfunction occurs, the primary workflow will halt, a solution will be selected from a library, and the work will continue from the point where the issue was detected. Górski et al. [45]  conducted a systematic literature review on the optimization of BP execution in a service architecture, the authors categorized relevant methods into three stages: resource allocation  [46, 47] , service composition, and service scheduling  [48, 49].
Library of Patterns The library of patterns is a database of patterns containing both atomic activities and sets of activities or a workflow. Unlike previous literature this library serves as a resource for storing fragments or full workflows without explicit mapping to specific deviations in process execution. The library of patterns can be viewed as a resource that can begin with no content and gradually expand to encompass thousands of workflows, ultimately serving to resolve deviations in process execution in an implicit manner. Different users contribute through collaboration. Moreover, it can be characterized by its input and output, required resources, and associated constraints, similar to how activities were previously characterized in Section Task Characterization in Section 3. 1.
Experiments and Results In order to showcase the proposed approach and to demonstrate how fast the elimination of non-compatible patterns can be, the authors selected a piece of honeybee BPMN model developed with help of amateur and professional beekeepers in Lebanon and France, and well discussed in a previous publication from the same authors  [16]. Before establishing the proof of concept for the bee hibernation model, the working environment was set up to interface with an existing BPMN model and process its tasks. Python 3. 9. 13 was chosen as the main scripting language as it includes a BPMN parsing package developed by Bocciarelli et al. [56]  called py-bpmn-0. 4. 0, which allows for straightforward data extraction. The Tkinter Python package was used to create a GUI to display the final report.
After setting up the environment, the first step was to extract all useful data from the given BPMN model in Figure  8  and access them inside the Python script. After specifying the path to the model's XML file, the py-bpmn-0. 4. 0 package scanned the file for its tags to map them to the respective tasks, gates, or conditions in the code. After iterating over all the tasks, the script gains access to the methods named after each task, allowing the developer to simulate an action that takes place either before, during, or after the respective task, as shown in Figure  9. Once the XML file is parsed, every task in the process gains access to a shared variable called the 'payload' (represents the state token, see Section 3. 1. 1), which is automatically updated after every executed task, as discussed in Section Task Characterization in Section 3.
def on_exit_task ( self, **kargs ):. def on_CheckDate ( self, **kargs ):. def on_CheckProvisions ( self, **kargs ):. def on_CheckProteinFeeding ( self, **kargs ):. def on_VarioseVaccineNovember ( self, **kargs ):. Once the ability to access and modify the BPMN information was verified, the focus was shifted to simulating deviations and writing alternative search algorithms. Given the lack of a meaningful BPMN model to hand, the alternative tasks were generated by another Python script that includes a list of possible constraints and their range of values. Upon running the script, a number of alternatives are generated based on a random selection of random constraints. To test the limits of the script, the chosen number of alternative tasks varied starting from 1000 and incrementally increased up to 2,000,000.
This allowed the measurement of the different elapsed times required to load and search through the tasks. The generated number of alternatives was usually slightly less than desired due to discarding duplicates. For the automated search, the main Python script was set to ensure that any constraint found within all the tasks was validated. Whenever a deviation or a mismatched constraint, is found, a method is triggered to search for alternative tasks among the generated pool that can fix the deviation. All alternatives are evaluated based on their entry constraints and their predicted exit values, depending on the number of remaining tasks in the process. For every alternative task, the entry constraints are first compared with the values in the current state token of the system. The number of mismatched constraints are recorded, and the alternatives are subject to a second round of filtering.
For alternative tasks that achieved total validity, i. e. , when entry constraints and exit values satisfy all conditions in the state token, the solution is displayed in its suggested location in the updated process. The constraints of the original and new tasks in the updated process are also available to be viewed by the user, as shown in Figure  13. It is noted that for alternative tasks that are able to be linked to more than one remaining task, multiple solutions are displayed showing the different possibilities that can be implemented. Upon examining the elapsed time for each of the two filtering stages, for a small number of alternative tasks (less than 100,000), the displayed time was a small fraction of a second. This is due to the fact that the search process required very little time to complete given the simplicity of its requirements, and the Python "time" package inaccurately measures time when the intervals are very small.
Increasing the number of generated alternatives increased the initial loading time and elapsed processing time, with greater precision. The elapsed times were recorded in multiple cases with a growing pool of generated alternative tasks as shown in Table  3. The number of patterns written in the second column represents the actual number of generated tasks due to the elimination of duplicates. The values below are listed in seconds and are the averages of multiple executions of the script on the same device. As expected, there was a notable increase in the total elapsed time as the pool of alternative tasks grew. Yet, despite reaching an unreasonable amount at around 2,000,000, the script was able to process all alternatives in a matter of seconds and produced a meaningful report for the user, saving them hours of manual planning.
By characterizing and formulating the approach, it was possible to easily add new characterizations to the existing BPMN elements and implement the entire approach using Python. This ease of implementation is a crucial factor in making the approach accessible and feasible for real-world applications, as it enables practitioners to quickly and efficiently incorporate it into their existing systems and workflows. In addition, the proposed iterative solution injection approach involves the system continuously analysing historical data to suggest optimizations at the main model level. By learning from past experiences and adapting to new circumstances, the system can continually improve its performance. This approach opens up new possibilities for artificial intelligence studies in the future, where the system could use the historical database to further enhance the model's design.
For this reason, digital simulation solutions are developed to massively test new and varied technologies under the most exhaustive conditions, which is not possible exclusively experimentally. The Horizon Europe ROADVIEW project (Robust Automated Driving in Extreme Weather), supporting this work, aims to address the impact of harsh weather conditions on automotive perception sensors. Work Package 3, devoted to digital simulation, will develop sensor noise modelling to represent the variations in harsh weather characteristics and thus generate realistic synthetic sensor data. The goal is to build automated vehicle testing by simulation-assisted methods. Cerema, equipped with its fog and rain PAVIN platform  [9, 10] , has carried out work for years with several national and international partners aimed at better understanding the behaviour of the perception systems of intelligent vehicles under harsh weather conditions  [11, 12].
Additionally, in support of its experimental work, Cerema is also interested in the theoretical aspects of electromagnetic wave propagation under adverse meteorological conditions, including fog, in order to meet the challenges of numerical simulation of autonomous vehicles in all weather conditions  [13]. Nowadays, there exist optical sensor simulators (for camera, radar and LiDAR) that consider atmospheric conditions such as fog or rain. We can cite some software: Ansys AVxcelerate Sensors [14], Carla Simulator  [15, 16] , Pro-SiVIC  [17] [18] [19] , Electro-Optics sensor simulation  [20, 21] , AVSimulation  [22] , 4DVirtualiz  [23] , Mitsuba  [24] , etc. Different electromagnetic wave propagation models are used in these simulators, ranging from simple Beer-Lambert type attenuation laws to complex offline ray-tracing simulations.
We now propose to verify the impact of the blurring on a realistic image. Then, we propose to set up metrics to confirm what we perceive visually thanks to a discussion of quantitative metrics on real and simulated images in the next section. The images in Figure  10  show a section of the French A75 highway, at the Col de la Fageole point, without fog (a) and with fog (b) (see  [42]  for a detailed description of the database). The image with fog (Figure  10b ) can be compared to the simulated images (Figures  6b  and 8b ). Although the latter are not made in the same scene, it still allows us to observe a similarity in the visual aspect of the fog in all these images (i. e. , blurry effects). This confirms the realism of the rendering performed by SWEET. In perspective, we will then propose simulations on this specific use case by reproducing the same scene as that of the Col de la Fageole.
The Koschmieder model shows deviations from the real images as can be seen in Figure  12d. Future work will consist of continuing the comparison between SWEET, Mitsuba and the Koschmieder model on a wider variety of images, for other levels of fog and for other metrics of interest that could be built on higher level indicators, such as VDP or obstacle detection algorithms, for example. The Koschmieder model could be extended by adding the consideration of halo effects, blurring, etc. as has been performed in  [26]  in order to be able to use it in support of other simulators while guaranteeing satisfactory realism. Moreover, it would be interesting to perform more applications using common datasets. It will also be useful to compare the physical radiance outputs of the SWEET simulator with experimental measurements acquired with a spectroradiometer or a hyperspectral camera using the PAVIN platform or real-world sites instrumented by Cerema and its partners.
Furthermore, ongoing work would complete future versions of SWEET with textures and BSDFs in order to get as close as possible to physical reality. Another perspective will be to build a database of images generated by SWEET in order to train machine learning algorithms able to deliver harsh weather noise models that can be run in real time. The work may also be extended to other wavelengths for cameras operating in SWIR and LWIR ranges or to active technologies such as LiDAR and RADAR.
Data streams are becoming omnipresent on the Web. The Stream Reasoning (SR) paradigm, which combines Stream Processing with Semantic Web techniques, has been successful in processing these data streams. The progress in SR research has led to several applications in domains such as the Internet of Things, social media analysis, Smart Cities, and many others. Each of these applications produces and consumes data streams, however, there are no fixed guidelines on how to manage data streams on the Web, as there are for their static counterparts. More specifically, there is no fixed life cycle for Streaming Linked Data (SLD) yet. Tommasini et al. (  2020 ) introduced an initial proposal for a SLD life cycle, however, it has not been verified if the proposed life cycle captures existing applications and no guidelines were given for each step.
Introduction The Semantic Web community has witnessed a growing interest in streaming data over the last decade. Under the Stream Reasoning (SR) umbrella, Semantic Web technologies were combined with Stream Processing ones to answer the research questions is it possible to make sense, in real-time, of heterogeneous, vast, incomplete, and noisy data streams coming from complex domains? This research question spans a number of application domains, including social media analytics, the Internet of Things for smart cities  [1, 2] , and cluster management  [3]. The research outcomes of SR include but are not limited to, findings on Continuous Querying over RDF Data, Incremental Reasoning, and Complex Event Recognition  [4]. In particular, the research around RDF Stream Processing (RSP) has been incredibly active.
Similar guidelines exist for non-streaming data, e. g. , the Linked Data Principles, which support the original vision of Sir Tim Barners-Lee, and the FAIR initiative, which provides principles to make data Findable, Accessible, Interoperable and Reusable. Together they inspired the first attempt to define a Streaming Linked Data (SLD) life cycle  [9]. Such a proposal identifies the life cycle steps starting from three situations a practitioner may find when dealing with SLD. Three possible starting points are identified, i. e. , Web Data published in batches; Linked Data published in batches; and Web Data published as streams. Although realistic, the work presented in  [9]  elicits the life cycle, neglecting an application perspective. In practice, a lot of attention is given to how to provision data, neglecting the important role of querying.
Despite RSP leading to the vision of SLD, best practices for sharing highly dynamic datasets on the Web are still missing. The existing proposal  [9]  does not fully capture the complexity of stream reasoning applications. Therefore, this paper presents a novel life cycle for SLD, which extends the one in  [9]  with best practices elicited from state-of-the-art SR/SLD applications. The new life cycle is depicted in Fig. 1. It consists of seven steps and aims at making data streams findable, accessible, reusable, and interoperable  [10]. In particular, the life cycle details how to publish SLD, indicating how to (i) identify and name data streams as Web resources, (ii)model data and metadata, (iii) shape the data, (iv) annotate the data into RDF, (v) describe the data to improve stream discovery, and (vi) serve the streaming data.
Survey methodology In particular, we aim at answering the following research questions: Are existing stream reasoning applications compliant with the proposed SLD lifecycle? Intuitively, in case of a negative response, we are interested to understand the reason for such a mismatch. Our analysis of the state-of-the-art follows the guidelines for systematic mapping studies proposed in  [15] , which were successfully applied to other surveys on the semantic web. In particular, we follow the same research protocol applied in  [15]. Reyero-Lobo et al. first collected relevant studies following a keyword-based search then applied different filters, i. e. , a sourcebased filter that discards non-relevant research areas; a metadatabased filter that inspects the title, abstract, venues, and years; a content-based filter which inspects the paper in details.
BOTTARI, which employs augmented reality applications for personalized and localized restaurant recommendations, was experimentally deployed in the Insadong district of Seoul. In BOTTARI, data is modeled using the SIOC and WGS-84 ontology. In order to convert the tweets to RDF, a hard-coded solution for annotation is used. Once annotated, the RDF data is served using websockets and queried using the C-SPARQL  [17]  RSP engine. The CityPulse project  [1]  handles a typical Smart City use case. The framework allows the development of applications that can provide a continuous and dynamic view of a city, making sense of social and sensor streams. To this extent, CityPulse employs semantic discovery, data analytics, and large-scale reasoning in real-time. CityPulse is built in a service-oriented manner combining RDF Stream Processing and Complex Event Processing.
The framework was demonstrated using live data from the city of Aarhus, Denmark. In CityPulse, the sensor data is annotated using a custom hard-coded solution, resulting in a stream producing graph shaped time-annotated events. The events themselves have been identified using random identifiers, allowing to differentiate between events. The SSN, PROV-O and OWL-S ontology are used to model the event data, while the SAO ontology is used the describe the streams themselves. The CQELS  [18]  RSP engine is used to query the RDF streams. SLD (which stands for Streaming Linked Data)  [19]  is a framework to collect, annotate, and analyze data streams. To this aim, SLD uses semantic technologies like RDF and SPARQL as well as techniques for sentiment mining. The framework follows the publication method proposed in  [20].
Running example As a running example, we will use the taxi dataset made available by ACM DEBS 2015 Grand Challenge. 9 The goal of the running example is to provide tangible examples for each of the steps of the updated lifecycle. The DEBS challenge consists of a taxi route analysis scenario in the city of New Year. The dataset consists of two streams: A ride stream that represents the route of a taxi rides in terms of (i) taxi description, (ii) pick-up and dropoff information (e. g. , geographical coordinates of the place and time of the event), and (iii) the number of passengers. The fare stream describes the ride payment information (e. g. , tip, payment type and total amount). In more detail, Table  3  describes the fields contained in the rides stream, while Table  4  describes the fields in the fare stream.
Note that the rideId, taxiId and driverId are contained in both streams. The dataset was used in the DEBS challenges to solve two queries: (1) finding the frequent routes and (2) detecting the most profitable areas. For the first query, the goal was to find the top 10 most frequent routes during the last 30 min. The second query aimed to identify areas that are, at a certain time, most profitable for taxi drivers. In the remainder of this paper, we will use the taxi dataset as a running example to detail the various steps of the life cycle.