Towards Provenance-Aware Earth Observation Workflows: the openEO Case Study

Towards Provenance-Aware Earth Observation Workflows: the openEO Case Study H. Omidi*1, L. Sacco*1, V. Hutter2, G. Irsiegler2, M. Claus3, M. Schobben4, A. Jacob3, M. Schramm4, S. Fiore1 1University of Trento, Trento, Italy 2Earth Observation Data Centre for Water Resources Monitoring GmbH, Vienna, Austria 3Eurac Research, Bolzano, Italy 4Vienna University of Technology, Vienna, Austria Abstract—Capturing the history of operations and activities during a computational workflow is significantly important for Earth Observation (EO). The data provenance helps to collect the metadata that records the lineage of data products, providing information about how data are generated, transferred, manipulated, by whom all these operations are performed and through which processes, parameters, and datasets. This paper presents an approach to improve those aspects, by integrating the data provenance library yProv4WFs within openEO, a platform to let users connect to Earth Observation cloud back-ends in a simple and unified way. In addition, it is demonstrated how the integration of data provenance concepts across EO processing chains enables researchers and stakeholders to better understand the flow, the dependencies, and the transformations involved in analytical workflows. Index Terms—Provenance, Earth Observation, openEO, WfMS I. INTRODUCTION Provenance, as a general concept, refers to the history of ownership of a valued object, and more specifically, data provenance refers to the process of tracking and capturing the origins and movement of data in the way we track the entire lifetime of data throughout a process [6]. In other words, data provenance could be considered as the metadata that records the lineage of data products. Provenance can be broadly categorized into two types [14]: prospective provenance describes the structure of a workflow, detailing the sequence of operations, tasks, and data dependencies as defined before execution. On the other hand, retrospective provenance captures what actually occurred during workflow execution, including the sequence of steps taken, input and output data, parameters used, execution timestamps, and outcomes. The tracking of provenance at the computational workflow enactment level guarantees the reproducibility and reliability of research processes in eScience [4]. This plays a critical role in Earth Observation (EO), as data is often processed through complex, multistage workflows that involve large-scale datasets, different data sources, and distributed processing tools. The concept of a workflow typically refers to a high-level overview of sequentially related procedures, encompassing * The two authors equally contributed to this work. all the steps involved. In the context of any application or activity pipeline, a workflow represents the complete sequence of operations throughout its life-cycle. Based on that, it is possible to provide valuable information about the whole procedure by capturing data and metadata about each activity and step. When talking about EO applications, tracking provenance can become a complicated task. The cost and complex nature of EO experiments make them difficult to monitor, consequently hindering transparency, reliability, and repeatability. A practical solution to improve these aspects is tracking provenance at the workflow level, which means capturing not only what (inputs and outputs) is produced during the workflow execution, but also how, where, when, by whom, and why each computational step has been carried out [29]. This detailed form of provenance is essential for tracking changes in EO training pipelines, especially when workflows are reused or updated over time [1]. In fact, tracked provenance makes research activities easier for scientists working on the same computational procedures, consistently reducing the efforts needed to reproduce scientific results. With the rise of federated EO processing systems, such as those enabled by openEO [27], tracking the provenance at the workflow enactment level has become even more important [26]. Federated environments provide the processing across multiple back-ends and make it challenging to trace how each component contributes to the final output. The provenance of the workflow level is fundamental to ensure reproducibility in these environments, as it allows users to reconstruct complete end-to-end processing chains across diverse infrastructures [2]. openEO has developed an API [7] based on different technologies for big Earth Observation in a simple and unified way, handling large amounts of data in the EO applications, giving an easy access to EO data and the necessary compute resources and functionality needed to work with such data. Specifically, it provides different back-ends to its users, also offering APIs developed under various programming languages as Python, R, and JavaScript. Moreover, it lets researchers focus on analytical tasks rather than data logistics. It makes EO access and processing standardized across different cloud platforms, although it also includes a version that can run on the local machine. 58 2025 IEEE International Conference on eScience (eScience) 2325-3703/25/$31.00 ©2025 IEEE DOI 10.1109/eScience65000.2025.00016 2025 IEEE International Conference on eScience (eScience) | 979-8-3315-9145-8/25/$31.00 ©2025 IEEE | DOI: 10.1109/eScience65000.2025.00016 Authorized licensed use limited to: EURAC Research Library. Downloaded on October 13,2025 at 09:56:51 UTC from IEEE Xplore. Restrictions apply. In this work, we introduce yProv4WFs [4] (a library from the yProv ecosystem [24] which provides provenance tracking across various Workflow Management Systems) and in particular its openEO extension, designed to address provenance tracking within the openEO framework. yProv4WFs helps openEO obtain provenance records for each executed workflow, extracting runtime metrics from all stages of an openEO use case or scenario and information about tasks, data, and the relationship between them. The paper is organized as follows: Section II reviews the related work while Section III introduces how to track provenance in the openEO platform. Section IV presents the yProv4WFs architecture and its components whereas Section V discusses the application of the proposed yProv4WFs extension for openEO to a real use case. Finally, Section VI draws the conclusions of the paper and provides future directions. II. RELATED WORK The tracking of provenance is a critical component in ensuring reproducibility, transparency and reliability, particularly in the context of long-running and complex computational processes [14]. The demand for open geospatial science, including both open data and open-source software, is rapidly increasing [8]. In parallel with the expansion of open geospatial platforms and the growing use of complex computational pipelines, various tools and standards have emerged to efficiently capture and represent provenance data while guaranteeing interoperability. Scientific workflows typically consist of a series of transformations, data manipulations, and computations that span multiple data sources, software components, and computing environments. Therefore, understanding the provenance, which includes the origin, evolution, and dependencies of data products, is critical for traceability and reusability [9], [23]. In the field of EO research, reproducibility is frequently compromised due to the absence of standardized provenance, especially when combining local and cloud-based infrastructure [10]. Ensuring the high quality and reproducibility of scientific data requires not only robust data processing infrastructures but also comprehensive provenance tracking throughout the data life-cycle. In [17], a work on the Atmospheric Radiation Measurement (ARM) program shows the critical importance of transparent quality control in atmospheric data streams. Recent efforts to improve scientific reproducibility and transparency have led to the development of structured, open workflows [30]. For example, Arnal et al. [19] introduced FROSTBYTE, a reproducible and modular forecasting pipeline implemented through Jupyter Notebooks and publicly shared on GitHub. Other studies have also emphasized reproducibility; for instance, Cuevas-Vicentt´ ın et al. [20] describe how scientific workflows can enhance both reproducibility and interoperability by automating computations and capturing provenance data. Although several provenance models offer robust support for retrospective provenance, they often lack sufficient expressiveness to capture prospective provenance in workflows involving control flow logic [21]. This can reduce workflow reproducibility, particularly in EO pipelines with conditional operations. Despite the availability of large-scale EO datasets and high-level APIs, such as openEO [2], workflow provenance is not automatically captured during processing. Provenance standards such as W3C PROV [25] offer an abstract data model to capture information about metadata that can be collected during the execution of workflows, but often require extensions to be customized with a specific implementation to be useful in complex workflows [11]. The provenance interoperability of a workflow management system across diverse workflows is also a challenge [28]. Although many provenance models aim for standardization, they often have semantic mismatches and system-specific implementations. Furthermore, complex provenance models are often challenging for non-expert users to interpret or reuse effectively. Some contributions are identified in RO-Crate [11] and CWLProv [13], which both provide tracked provenance for workflows using structured metadata containers and JSONLD-based [22] ontologies. RO-Crate, for example, separates prospective and retrospective provenance and packages workflow artifacts for reusability. Although Ro-Crate is using some terms such as HowToStep and FormalParameter that limit the clarity in representing workflow dependencies, especially for users unfamiliar with semantic models. Even though provenance tracking at the workflow level can significantly support reproducibility, it may not be sufficient in cloud-based environments. According to Hasham, Munir, and McClatchey [12], ensuring reproducibility in cloud-based EO platforms is particularly challenging, as users often lack clear and comprehensive access to the underlying computational environment. Therefore, provenance systems designed for the cloud must capture both workflow-level and infrastructure. In this context, we introduce a yProv4WFs extension for the openEO platform to improve usability, reproducibility, and interoperability. It is developed in compliance with the PROVO1, also improving the expressiveness and navigability of the workflow steps. III. TRACKING PROVENANCE IN THE OPENEO PLATFORM openEO is an open API designed to unify access to cloudbased EO processing services, and it also supports local processing through compatible Python libraries. It provides a standardized interface that helps the users utilize the different EO back-ends, enabling scalable and cross-platform geospatial analytics. Through client libraries in Python, R, and JavaScript, openEO abstracts the complexity of the underlying infrastructures, allowing users to construct workflows that are portable and interoperable [3]. The Python implementation of openEO is structured around a modular architecture consisting of three main packages: openeo-python-client2, openeo-pg-parser-networkx3, and 1https://www.w3.org/TR/prov-o/ 2https://github.com/Open-EO/openeo-python-client 3https://github.com/Open-EO/openeo-pg-parser-networkx 59 Authorized licensed use limited to: EURAC Research Library. Downloaded on October 13,2025 at 09:56:51 UTC from IEEE Xplore. Restrictions apply. openeo-processes-dask4. Each of these components plays a distinct role in the client-side definition, parsing, and execution of Earth Observation workflows. Figure 1 illustrates the schematic relationship between these packages. Fig. 1: Schematic relationship between the different packages in openEO implementation openeo-python-client provides a high-level interface for users to connect to openEO back-ends, build workflows, and manage jobs. It abstracts communication and offers a user-friendly API for defining process graphs. A process graph is a sequence of specific processes, each of which has its own concrete values for input parameters. Process graphs organize a pipeline of processes and automate pipeline execution5. openeo-pg-parser-networkx parses process graphs into networkx-based structures, enabling validation and traversal. It is essential for interpreting and analyzing the graph representation of workflows. Moreover, when referring to the python implementation, it produces the actual executable object, which the process graph represents. openeo-processes-dask provides python implementations of openEO processes, using the Xarray and Dask frameworks for scalable and efficient data processing. It is designed to be used with openeo-pg-parser-networkx, which is responsible for parsing and executing openEO process graphs. A. Tracking provenance on the Local Processing openEO has been developed as an API that enables users to define EO workflows using a lightweight client, while delegating the computationally intensive tasks, such as data access and processing, to the back-end systems. However, this model of remote execution and abstraction from the underlying file structures can sometimes result in workflows that fail and are challenging to debug. Each trial-and-error iteration requires establishing a connection to the back-end, waiting for the process graph to be initialized (once the necessary resources become available), and subsequently reviewing logs if the processing fails again. To address these limitations, openEO supports local (client-side) processing. This functionality leverages the following Python libraries, integrated in the openEO Python client: (i) openeo-processes-dask – an implementation of openEO processes based on Xarray and Dask, facilitating scalable, parallel processing. (ii) openeo-pg-parser-networkx – a parser for openEO 4https://github.com/Open-EO/openeo-processes-dask 5https://api.openeo.org/v/0.3.0/processgraphs/ process graphs (in JSON format) that transforms them into callable Python functions, using implementations provided by openeo-processes-dask. It is important to note that these libraries are not limited to local processing. They are also integrated into certain backend systems, such as those operated by EODC and Eurac Research. This dual usage allows users to prototype and test their openEO workflows locally, gaining insight into the expected behavior on the target back-end. As a result, users can identify and resolve issues more efficiently and with greater confidence. B. Tracking provenance on the Remote Processing The openEO platform allows users to outsource their processing to a list of remote back-ends. These back-ends offer a range of data sources which can be used in the creation of process graphs directly and they are generally federated so that the user can access all of them from a centralized interface. Each back-end has to expose the openEO API, defined by openEO API specification, which standardizes the formatting of requests for submitting process-graphs, managing results, starting computations and user-management, etc. Back-ends share a broadly overlapping structure, but the implementation details regarding compute, workflow-management or database structures may vary. Working with remote processing closely resembles the local workflow, users create process-graphs, but instead of executing them on their own machines, the process-graphs are sent to a given back-end depending on the selected data-source. Then, the user can start the processing manually and the current status (Queued, Running, Error, Finished) of the processing job will be displayed and processing logs will be made available. After the job is finished, the user will be given a list of signed URLs pointing to the resulting files which they can either visualize directly in the interface or download individually. Additionally, the Spatio Temporal Asset Catalog (STAC)6resources will be created for each result and exposed alongside the data (each with their own signed URL). STAC is both a standard and a collaborative community initiative aimed at enhancing access to geospatial information about our planet. Its primary objective is to simplify the process for data providers to make their datasets openly accessible and discoverable by a global audience. C. Workflows Execution in openEO It is important to distinguish between a workflow in the context of a Workflow Management System and a workflow within the openEO platform. In classic WfMSs workflows are explicit task-based execution graphs, often written in Python or a domain-specific language, which define how to execute, manage scheduling, retries, parallelism, and infrastructure. In contrast, openEO workflows are high-level declarative process graphs that describe what EO operations should be applied (e.g., filtering, aggregation, NDVI computation), without detailing how the execution is managed. 6https://stacspec.org/en/about/ 60 Authorized licensed use limited to: EURAC Research Library. Downloaded on October 13,2025 at 09:56:51 UTC from IEEE Xplore. Restrictions apply. Fig. 2: openEO workflow with three steps The openEO API standard offers a unified interface for EO data processing across different back-end providers. When using the openeo-python-client7library, users build workflows by chaining operations in the form of process graphs, which are serialized to JSON and sent to a compliant back-end for execution. Users add different steps or process nodes to this workflow, each of which performs a specific task or activity. Figure 2 shows an example of a three steps workflow carried out by the openEO Python client module. Each box corresponds to a specific process node with its own parameters and functionality. The load_stac node initializes the workflow by specifying parameters such as bands, spatial extent, temporal range, and data source URL. The reduce_dimension node performs a specific transformation, reducing data across a selected dimension (e.g. bands or time). The connections between boxes illustrate the data flow, with each process building on the output of the previous to form a complete modular workflow. A typical workflow in an openEO use case includes the following steps: •Process Graph Construction: using ProcessBuilder, users create graphs that represent a series of EO operations (e.g., spatial filtering, temporal aggregation). •Graph Submission: the graph is sent to a back-end. In the case the user is using the local process, the back-end would be on the local machine. •Back-End Execution: the back-end interprets and executes the graph using its internal engine, which may rely on frameworks such as Dask, Airflow, or other orchestrators [3]. •Result Retrieval: the output is returned as a file, visual object, or downloadable link. IV. THE YPROV4WFS ARCHITECTURE A. yProv yProv [18] is an open source software ecosystem that has been developed based on the W3C PROV8family of standards and contains a graph database back-end based on Neo4J. yProv is domain-agnostic and made of different components, including yProv4WFs, which has been developed for tracking provenance of workflows. Figure 3 shows the relationship between the different components of the yProv ecosystem. 7https://open-eo.github.io/openeo-python-client/ 8https://www.w3.org/TR/prov-overview/ Fig. 3: yProv ecosystem with the different components B. yProvExplorer The yProvExplorer9is a data science application to help scientists access and navigate provenance documents. It is developed in Javascript and through specific libraries (i.e. React and D3.js) offers dynamic and interactive navigation of the provenance as a graph. All the components of provenance are distinguished by color and shape to provide a user-friendly exploring experience to the end user. It also provides other features such as navigation through history and graph statistics, and so on, which help the end user have proper tools to evaluate and compare the workflow provenance. C. yProv4WFs yProv4WFs [4] is a Python-based library to track provenance in complex scientific workflows across diverse WfMSs (see yProv4Cylc and yProv4Streamflow in Figure 3, where Cylc [15] and Streamflow [16] are both WfMSs). It has been developed in compliance with the W3C PROV standards and designed according to the data model reported in Figure 4. It enables detailed and standardized recording of data lineage, task dependencies, and execution context within computational workflows. It functions as an external, third-party service, making it agnostic to specific WfMS implementations and suitable for heterogeneous, multi-system environments. D. yProv4WFs extension for openEO The yProv4WFs extension for openEO is designed to enable workflow-level provenance tracking in the openEO platform. It 9https://github.com/HPCI-Lab/yprov-explorer/ 61 Authorized licensed use limited to: EURAC Research Library. Downloaded on October 13,2025 at 09:56:51 UTC from IEEE Xplore. Restrictions apply. Fig. 4: yProv4WFs UML class diagram [4] works based on the data model developed for yProv4WFs (Figure 4), ensuring compatibility with its provenance structure and semantics. The implementation phase of such work started on the local processing offered by the openEO API, where the execution of process graphs is simulated or executed directly in Python without involving a remote back-end. This approach provided greater control and flexibility during development and debugging. Through a detailed analysis of the internal structure of the openEO process graph, provenance calls have been injected into the openeo-pg-parser-networkx package. This package parses openEO process graphs into NetworkX DAGs, making it a natural entry point for tracking the execution flow at the node level. In particular, yProv4WFs calls have been embedded by identifying key traversal and execution points in the process graph parsing logic. The functions responsible for walking the graph nodes and executing corresponding processes have been targeted. These locations have been selected because they represent well-defined operational units (e.g., apply, reduce dimension) where data is transformed or moved. At each of these points, lightweight wrappers or explicit calls have been added to log inputs, outputs, execution time, and contextual metadata. Figure 5 shows openEO source code structure and where yProv4WFs exploits its calls to collect data and metadata information. The graph representation provided by the openeo-pg-parser-networkx package allows to systematically look over each node of the process graph, where each of them represents an EO operation or activity, Fig. 5: openEO internal architecture (parser) and its integration with yProv4WFs and record runtime metadata such as the start time, end time, duration, and intermediate outputs. In the case of failure for an activity during workflow execution, yProv4WFs still captures and stores provenance metadata. Each failed activity node in the workflow is associated with a status field, enabling users to inspect partial executions and identify the step where failure occurred. All information is used to build a detailed provenance graph that reflects the actual data flow and computation within the workflow. Once extracted, the provenance documents are stored through the yProv service, ensuring that they are persistently available for later retrieval, analysis, and sharing. Following the successful and validated integration of the local processing capabilities provided by the openEO API, the focus shifted to remote execution. The same methodology was applied to enable provenance capture during the execution of jobs on remote EO infrastructures. By embedding the same node-level tracking into the back-end workflow engine, we aim to achieve consistent and transparent provenance across both local and remote executions, laying the foundation for end-toend reproducibility and traceability in openEO workflows. V. TRACKING PROVENANCE IN THE OPENEO-FLOOD-MAPPER To validate the integration of yProv4WFs into the openEO platform, a set of representative EO workflows was used. Specifically, the openeo-flood-mapper10 offered by the Vienna University of Technology as part of the interTwin11 project is considered for the experimental part. A. openeo-flood-mapper description The openeo-flood-mapper is a Python-based module for mapping flood extent using Sentinel-1 SAR data, based on openEO commands. The module implements a Bayesian inference approach [5] to identify flood extents by comparing observed backscatter values with expected values over land and water surfaces. It makes use of Sentinel-1 sigma nought (σ0)backscatter data (level 1C) organized in a data cube, enabling time series analysis on a per-pixel basis. Since not only water surfaces lead to low backscatter values, a contextual and probabilistic approach is required to distinguish water from non-water areas. Therefore, the 10https://github.com/interTwin-eu/openeo-flood-mapper-local 11https://www.intertwin.eu/ 62 Authorized licensed use limited to: EURAC Research Library. Downloaded on October 13,2025 at 09:56:51 UTC from IEEE Xplore. Restrictions apply. expected backscatter values of non-flooded land are modeled using harmonic regression on long-term historical Sentinel-1 observations. This allows the algorithm to capture seasonal backscatter variations and estimate the expected value of a non-flooded pixel for a specific day-of-year [5]. This information, as well as backscatter statistics of known water pixels, is used in a Bayesian approach for estimating the probability of a flooding. In turn, a Bayesian decision comparing posterior probabilities of flood versus non-flood allows the classification of a pixel being flooded. Finally, the flood mapper tracks changes on the Earth’s surface over time, investigating temporal variations in Sentinel1 SAR backscatter data to monitor surface dynamics. By examining time series at selected locations, the study aims to identify consistent trends and anomalies in surface reflectivity. This shows the importance of decision reliability by proposing the denial of decisions under conditions of high uncertainty, thus reducing the risk of misclassifications or erroneous interpretation in downstream applications. B. Provenance output on different infrastructure As previously mentioned, openEO offers two distinct modes of use. On one hand, the local processing requires additional setup on the user’s machine, including the installation of the openEO Python client and its dependencies. In this mode, the workflow execution is handled entirely by local resources. On the other hand, the remote processing leverages cloud-based infrastructure to execute openEO workflows, offloading the computational tasks from the local environment. To run the use case on the local machine the following packages have been installed: openeo-python-client; openeo-pg-parser-networkx>=2023.5.1; openeo-processes-dask>=2023.7.1. The openeo-flood-mapper has been run both locally and remotely to process satellite-based flood detection workflows. The yProv4WFs extension for openEO enables full provenance tracking in both cases, allowing detailed inspection of each step of the data flow. The gathered information is then stored in a JSON file following the W3C PROV standards and it is successively used to generate the corresponding provenance graph. Figure 6 illustrates how the function water_backscatter in the openeo-flood-mapper is mapped to an openEO process graph and subsequently how each sub-function can be plotted in the provenance graph. The four different colours, pink, green, orange and red, respectively identify: plia_dc, which is the dataset used for the experiment and in the provenance graph it is shown how data are uploaded for the experiment through the invocation of the load function; apply which applies the global linear model, using slope and intercept, to the incidence angle band to estimate the expected water backscatter; reduce_dimension which reduces the result over time using a mean reducer; add_dimension which reintroduces a ’bands’ dimension and assigns the label ’wbsc’ to the output as a new band for the water backscatter. To deeply understand Figure 6, each operational node in the process graph could have a sub-process graph, which is not represented in the figure for space reasons. Furthermore, each operational node corresponds to an activity in the provenance graph and activities are represented using blue rectangles. Green ovals, instead, represent data in input or in output to the different activities, and can be recognized on the base of the type of connections shown on the directed edges. White rectangles contain extra information about the activity or the entity to which are linked (i.e. execution time and status of an activity or type and dimensions for the entity). This integrated visualization demonstrates how openEO workflows defined in Python code can be systematically parsed, executed, and documented using the yProv4WFs library. The complete execution of the openeo-flood-mapper is shown in Figure 7. For a better visualization the yProvExplorer service has been exploited, allowing to appreciate the complexity of the use case. This interactive visualization, provided by the yProvExplorer, allows users to explore how data and tasks are linked during workflow execution of the openeoflood-mapper use case. Each activity node corresponds to an operation in the process graph, while entity nodes represent input data. VI. CONCLUSION AND FUTURE WORK In this work, it has been demonstrated how data provenance can be implemented at the workflow level within the openEO platform, supporting both local and remote processing. By integrating the yProv4WFs data model with the parsing stage of openEO workflows, provenance information that contributes to key goals, such as transparency, trustworthiness, and repeatability, have been captured. The implementation of yProv4WFs provides a solution for workflow-level provenance tracking that is independent of the source infrastructure, capturing relevant aspects of the execution data produced by openEO and fully adhering to the W3C PROV standard. The Flood Mapper use case, employed as a test scenario, illustrates the extraction of the provenance graph, and the results have been presented in this paper. Future work will focus on integrating yProv4WFs with other platforms for running scientific workflows, with a particular focus on Earth Observation (EO) frameworks. Planned developments will include the implementation of debugging tools that leverage provenance records, allowing researchers to revert to steps prior to an error or rerun only the affected workflow segments with additional diagnostics or localized changes. Another promising future direction is to study the scalability of yProv4WFs in large-scale workflows, including evaluating performance metrics such as the computational overhead, carbon emissions caused by provenance tracking and temporal comparisons for workflows with different provenance configurations. Such an analysis would help optimize the framework for operational use in high-throughput computing environments. Finally, ongoing work will address the secure sharing and archiving of generated provenance data. 63 Authorized licensed use limited to: EURAC Research Library. Downloaded on October 13,2025 at 09:56:51 UTC from IEEE Xplore. Restrictions apply. Fig. 6: Representation of the water backscatter Python function into an openEO process graph and in its corresponding provenance graph using yProv4WFs. ACKNOWLEDGMENT This work was funded by the EU HE interTwin project (GA 101058386) and the EU HE Climateurope2 project (GA 101056933). Moreover, this work was partially funded under the NRRP, Mission 4 Component 2 Investment 1.4, by the European Union – NextGenerationEU (proj. nr. CN 00000013). 64 Authorized licensed use limited to: EURAC Research Library. Downloaded on October 13,2025 at 09:56:51 UTC from IEEE Xplore. Restrictions apply. Fig. 7: openeo-flood-mapper representation through the yProvExplorer https://explorer.yprov.disi.unitn.it/?file=http%3A%2F%2Fyprov.disi.unitn.it%3A3000%2Fapi%2Fv0%2Fdocuments%2Fyprov4wfs 65 Authorized licensed use limited to: EURAC Research Library. Downloaded on October 13,2025 at 09:56:51 UTC from IEEE Xplore. Restrictions apply. REFERENCES [1] H. Tan, P. Yue, D. Yu, S. Boyi and Z. Cao, ”A provenanceaware method for updating Earth Observation training data,” 2022 10th International Conference on Agro-geoinformatics (AgroGeoinformatics), Quebec City, QC, Canada, 2022, pp. 1-6, doi: 10.1109/ Agro-Geoinformatics55649.2022.9859187 [2] Mohr, M., Pebesma, E., Dries, J. et al. Federated and reusable processing of Earth observation data. Sci Data 12, 194 (2025). https://doi.org/10. 1038/s41597-025-04513-y [3] Pebesma, E., Wagner, W., Schramm, M., Von Beringe, A., Paulik, C., Neteler, M., Reiche, J., Verbesselt, J., Dries, J., Goor, E., Mistelbauer, T., Briese, C., Notarnicola, C., Monsorno, R., Marin, C., Jacob, A., Kempeneers, P., & Soille, P. (2017). openEO – a Common, Open Source Interface Between Earth Observation Data Infrastructures and Front-End Applications. Zenodo. https://doi.org/10.5281/zenodo.1065474 [4] Sacco, L., Sopranzetti, C., & Fiore, S. (2024). Enabling Provenance Tracking in Workflow Management Systems. In Proceedings of the 2024 IEEE International Conference on Big Data (BigData) (pp. 1–10). IEEE. https://doi.org/10.1109/BigData62323.2024.10825405 [5] Bauer-Marschallinger, B., Cao, S., Tupas, M.E., Roth, F., Navacchi, C., Melzer, T., Freeman, V., & Wagner, W. (2022). Satellite-Based Flood Mapping Through Bayesian Inference from a Sentinel-1 SAR Datacube. Remote Sensing, 14(15), 3673. https://doi.org/10.3390/rs14153673 [6] Buneman, P., Khanna, S., & Tan, W.-C. (2000). Data provenance: Some basic issues. In S. Kapoor & S. Prasad (Eds.), FSTTCS 2000: Foundations of Software Technology and Theoretical Computer Science (pp. 87–93). Springer. https://doi.org/10.1007/3-540-44450-5 6 [7] Schramm, M. et al. (2021). The openEO API–Harmonising the use of Earth Observation cloud services using virtual data cube functionalities. Remote Sensing, 13(6), 1125. https://doi.org/10.3390/rs13061125 [8] Mobasheri, A., Mitasova, H., Neteler, M., Singleton, A., Ledoux, H., & Brovelli, M. A. (2020). Highlighting recent trends in open source geospatial science and software. Transactions in GIS, 24(5), 1141–1146. https://doi.org/10.1111/tgis.12703 [9] Di, L., Yue, P., Ramapriyan, H. K., & King, R. L. (2013). Geoscience data provenance: An overview. IEEE Transactions on Geoscience and Remote Sensing, 51(11), 5065–5072. https://doi.org/10.1109/TGRS. 2013.2242478 [10] Kedron, P., & Frazier, A. E. (2022). How to improve the reproducibility, replicability, and extensibility of remote sensing research. Remote Sensing, 14(21), 5471. https://doi.org/10.3390/rs14215471 [11] S. Leo, et al. Recording provenance of workflow runs with RO-Crate, 2023, arXiv:2312.07852 https://doi.org/10.48550/arXiv.2312.07852 [12] Hasham, K., Munir, K., & McClatchey, R. (2018). Cloud infrastructure provenance collection and management to reproduce scientific workflow execution. Future Generation Computer Systems, 86, 799–820. https: //doi.org/10.1016/j.future.2017.07.015 [13] Khan, F. Z., Soiland-Reyes, S., Sinnott, R. O., Lonie, A., Goble, C., & Crusoe, M. R. (2019). Sharing interoperable workflow provenance: A review of best practices and their practical application in CWLProv. GigaScience, 8(11), giz095. https://doi.org/10.1093/gigascience/giz095 [14] S. B. Davidson and J. Freire. 2008. Provenance and scientific workflows: challenges and opportunities. ACM SIGMOD 2008, USA, 1345–1350. https://doi.org/10.1145/1376616.1376772 [15] Oliver et al., (2018). Cylc: A Workflow Engine for Cycling Systems . Journal of Open Source Software, 3(27), 737, https://doi.org/10.21105/ joss.00737 [16] I. Colonnelli, B. Cantalupo, I. Merelli, and M. Aldinucci, “StreamFlow: cross-breeding cloud with HPC,” in IEEE Transactions on Emerging Topics in Computing, vol. 9, iss. 4, p. 1723-1737, 2021. doi: https: //doi.org/10.1109/TETC.2020.3019202 [17] J. Kumar et al., ”Provenance–aware workflow for data quality management and improvement for large continuous scientific data streams,” 2019 IEEE International Conference on Big Data (Big Data), Los Angeles, CA, USA, 2019, pp. 3260-3266, doi: https://doi.org/10.1109/ BigData47090.2019.9006358. [18] S. Fiore et al., ”A Graph Data Model-based Micro-Provenance Approach for Multi-level Provenance Exploration in End-to-End Climate Workflows,” IEEE BigData2023, Sorrento, Italy, 2023, pp. 3332-3339. doi: https://doi.org/10.1109/BigData59044.2023.10386983 [19] Arnal, L., Clark, M. P., Pietroniro, A., Vionnet, V., Casson, D. R., Whitfield, P. H., Fortin, V., Wood, A. W., Knoben, W. J. M., Newton, B. W., and Walford, C.: FROSTBYTE: a reproducible data-driven workflow for probabilistic seasonal streamflow forecasting in snowfed river basins across North America, Hydrol. Earth Syst. Sci., 28, 4127–4155, https://doi.org/10.5194/hess-28-4127-2024,2024. [20] Cuevas-Vicentt´ ın, V., Dey, S., K¨ ohler, S. et al. Scientific Workflows and Provenance: Introduction and Research Opportunities. Datenbank Spektrum 12, 193–203 (2012). https://doi.org/10.1007/s13222-012-0100-z [21] A. S. Butt and P. Fitch, “A provenance model for control-flow driven scientific workflows,” Data Knowl. Eng., vol. 131, 2021,Art. no. 101877. https://doi.org/10.1016/j.datak.2021.101877 [22] Sporny M. et al. JSON-LD 1.0. W3C Recommendation 16 January 2014. http://www.w3.org/TR/2014/REC-json-ld-20140116/ [23] S. Fiore et al., ”Towards an Open (Data) Science Analytics-Hub for Reproducible Multi-Model Climate Analysis at Scale,” 2018 IEEE International Conference on Big Data (Big Data), Seattle, WA, USA, 2018, pp. 3226-3234. doi:10.1109/BigData.2018.8622205. [24] G. Padovani et al., ”A software ecosystem for multi-level provenance management in large-scale scientific workflows for AI applications,” SC24-W: Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis, Atlanta, GA, USA, 2024, pp. 2024-2031. doi:10.1109/SCW63240.2024.00253 [25] Paolo Missier, Khalid Belhajjame, and James Cheney. 2013. The W3C PROV family of specifications for modelling provenance metadata. In Proceedings of the 16th International Conference on Extending Database Technology (EDBT ’13). Association for Computing Machinery, New York, NY, USA, 773–776. https://doi.org/10.1145/2452376.2452478 [26] Yogesh L. Simmhan, Beth Plale, and Dennis Gannon. 2005. A survey of data provenance in e-science. SIGMOD Rec. 34, 3 (September 2005), 31–36. https://doi.org/10.1145/1084805.1084812 [27] A. Jacob et al., ”Openeo Platform - Federated Data Access and Processing Using Open and Commercial Earth Observation Data,” IGARSS 2023 - 2023 IEEE International Geoscience and Remote Sensing Symposium, Pasadena, CA, USA, 2023, pp. 276-278, doi: 10.1109/IGARSS52108.2023.10282703 [28] Asuman Dogac, T. Ozsu, and L. Kalinichenko. 2001. Workflow Management Systems and Interoperability (1st. ed.). Springer-Verlag, Berlin, Heidelberg. [29] Melanie Herschel, Ralf Diestelk¨ amper, and Houssem Ben Lahmar. 2017. A survey on provenance: What for? What form? What from? The VLDB Journal 26, 6 (December 2017), 881–906. https://doi.org/10. 1007/s00778-017-0486-1 [30] K. Alam and B. Roy, ”Challenges of Provenance in Scientific Workflow Management Systems,” 2022 IEEE/ACM Workshop on Workflows in Support of Large-Scale Science (WORKS), Dallas, TX, USA, 2022, pp. 10-18, doi:10.1109/WORKS56498.2022.00007 66 Authorized licensed use limited to: EURAC Research Library. Downloaded on October 13,2025 at 09:56:51 UTC from IEEE Xplore. Restrictions apply.