REVIEW 3 major objections 5 minor 22 references
Towards Provenance-Aware Earth Observation Workflows: the openEO Case Study
T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash
Pith's one-line read Every openEO workflow step now gets a W3C-PROV provenance record
desk verdict A concrete but narrow engineering report: local openEO provenance via yProv4WFs is real, remote provenance is still an aim. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The load-bearing mechanism is an extension of yProv4WFs, a Python provenance library for workflow management systems, that injects provenance calls into openeo-pg-parser-networkx, the openEO component that parses declarative process graphs into a directed acyclic graph of operations. Each graph node corresponds to one Earth-observation operation or activity; the injected calls record runtime metadata for the node and the relationships between data entities and activities, and the collected records are written out as W3C-PROV-compliant JSON that can be rendered in the yProvExplorer graph viewer.
What would settle it
Run an openEO workflow whose process graph contains a node with a nested sub-process graph on a remote back-end, save the yProv4WFs JSON, and compare it with the back-end's own execution logs: if the back-end carries out internal operations that the parsed process graph does not show, those operations will be missing from the provenance record.
Extended reading notes
Core claim
The paper's central claim is that workflow-level provenance in openEO can be captured without changing user-facing workflow definitions: instrumenting the parser that turns openEO process graphs into executable objects is enough to record each process node as a provenance activity with its runtime metadata, including start time, end time, duration, status, and intermediate outputs. These records are assembled according to the yProv4WFs data model, which follows the W3C PROV standard, and can be stored as JSON and visualized as a provenance graph. The same node-level tracking is applied to local processing through the openEO Python stack, and the paper states the aim of embedding it in remote back-ends so that provenance is captured consistently across both execution modes.
Load-bearing premise
The approach assumes that every operation that affects the final result is one of the process-graph nodes the parser walks, so recording each parsed node records every meaningful step, including nested sub-process graphs and steps executed inside remote back-ends.
Editorial extensions
If this is right
- Users of openEO can obtain a standardized W3C-PROV provenance record for a workflow without writing tracking code themselves, because provenance is captured at the parsing stage.
- Because the parser is shared by local execution and by some remote back-ends, provenance records from local prototyping and from cloud runs can be compared on the same structure, making it easier to debug failures and reproduce results.
- The openeo-flood-mapper workflow shows that a real Bayesian flood-mapping computation can be represented as a provenance graph whose activities and data entities correspond to the operations in the original process graph.
- Provenance results can be exposed alongside other openEO outputs in the same way that result assets are made available, so the lineage of a result is discoverable by downstream users.
- The integration point is an infrastructure-agnostic parser, so the same injection approach can be carried over to additional Earth-observation platforms as the paper's planned extension.
Reading between the lines
- If provenance is captured only at the parser's node level, back-end optimizations that fuse or rewrite process nodes would produce records describing the submitted workflow rather than the actual executed operations; a natural extension is to compare parser-level records with back-end engine logs on a workflow that triggers such optimizations.
- The per-node duration and status metadata in the provenance graph could be reused as a performance profile, letting users identify which Earth-observation operation dominates runtime without adding separate instrumentation.
- The same injection point could be adopted by other declarative workflow systems: any platform that parses a high-level operation graph into an executable DAG could record comparable PROV-compliant lineage by instrumenting its own parser.
- For stronger reproducibility, the provenance record could be extended with environment fingerprints, such as software versions, container identifiers, and data-collection hashes, alongside runtime metadata, so the recorded 'how' also pins down the exact execution environment.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper presents an extension of the provenance library yProv4WFs to the openEO Earth Observation platform, with the goal of producing W3C-PROV-compliant workflow-level provenance records for openEO process graphs. The extension is implemented by injecting provenance calls into the openeo-pg-parser-networkx package, which parses openEO process graphs into NetworkX DAGs and executes them locally. The authors describe the yProv ecosystem, the provenance data model, and demonstrate the approach on the openeo-flood-mapper use case, showing a provenance graph rendered through yProvExplorer. The paper claims support for both local and remote openEO executions, but the remote part is presented only as an aim in Section IV.D and no remote provenance output or evaluation is shown. The central demonstrated contribution is therefore local provenance capture for openEO process graphs, with remote provenance presented as future or ongoing work.
Significance. If the local provenance capture works as described, the paper makes a useful engineering contribution: it connects an established W3C-PROV-compliant provenance model (yProv4WFs) to a widely used EO workflow API (openEO), at a level that is infrastructure-agnostic with respect to the client-side parser. The demonstration on a realistic flood-mapping workflow is concrete, and the use of a standard provenance model is a strength for interoperability. However, the significance is currently limited in two ways. First, openEO's main value proposition is federated remote execution across back-ends, and the paper does not demonstrate provenance for that mode; the strongest claim in the abstract and conclusion goes beyond the evidence. Second, the paper does not validate completeness of the captured provenance beyond showing a graph that resembles the input process graph. The contribution is still publishable after revision if the claims are calibrated to what is actually implemented and evaluated.
major comments (3)
- [IV.D, V.B, VI] The paper's central claim that the extension supports both local and remote processing is not supported by the reported work. Section IV.D states that for remote execution 'we aim to achieve consistent and transparent provenance', and no remote provenance graph, log, or evaluation is presented anywhere. Yet Section V.B asserts that the extension 'enables full provenance tracking in both cases', and Section VI repeats that the work demonstrates provenance 'supporting both local and remote processing'. This is a load-bearing contradiction. The authors should either present evidence of remote provenance capture (e.g., a provenance document produced from a job executed on an openEO back-end) or explicitly restrict the claimed contribution to local processing and list remote provenance as future work.
- [IV.D, V.B] The instrumentation point in openeo-pg-parser-networkx only observes nodes in the parsed NetworkX DAG. Section V.B itself notes that 'each operational node in the process graph could have a sub-process graph, which is not represented in the figure'. The paper does not explain whether such sub-process graphs are expanded when provenance is recorded. If they are not expanded, the provenance graph omits internal steps and intermediate data of nested processes, which would contradict the claim in Section VI that the data model 'effectively captures all relevant aspects of provenance in openEO workflows'. Please clarify the granularity at which nested process graphs are captured and provide evidence that sub-process executions appear in the provenance document, or weaken the completeness claim.
- [VI] The statement 'We have validated that the yProv4WFs data model ... effectively captures all relevant aspects of provenance' is not backed by a validation protocol. The demonstration in Section V.B consists of one example provenance graph (Figures 6 and 7) with no comparison against the set of operations actually executed, no completeness metric, and no measurement of runtime overhead. For an engineering claim about provenance coverage, the authors should provide a concrete check, for instance verifying that every executed process, input parameter, intermediate product, and output of the flood-mapper appears in the generated PROV document, or otherwise state the coverage limitations explicitly.
minor comments (5)
- [V.B, Figure 6] The text describes four colors (pink, green, orange, red) for different components of the provenance graph, but Figure 6 does not appear to include a legend or color labels; please add a legend or label the nodes directly so the mapping is unambiguous.
- [V.B] The term 'plia_dc' is used without a definition or explanation of its role as a dataset; a brief description would help readers who are not familiar with the flood-mapper use case.
- [III.B] The sentence 'The provenance results will be made accessible in the same way' refers to STAC resources, but no implementation or example of this accessibility is provided; please clarify whether this is planned or already available.
- [II] The related-work discussion would be clearer if the comparison with RO-Crate, CWLProv, and other provenance approaches were summarized in a short table or with explicit criteria, rather than as a narrative list.
- [Various] There are minor typographical and consistency issues throughout, such as 'Ro-Crate' versus 'RO-Crate', a missing space before 'This integrated visualization', and a few run-on sentences; these should be corrected in a final copyedit.
Circularity Check
No significant circularity: provenance extraction is an engineering trace, not a derived prediction.
full rationale
The paper's central claim is an engineering capability: by instrumenting the openeo-pg-parser-networkx package with yProv4WFs calls, it produces W3C-PROV-compliant workflow-level provenance records for openEO local (and, as an aim, remote) executions. There are no fitted parameters, no equations, and no derived quantity that reduces to its own input by construction. The provenance graph is produced from the parser's own node-level execution trace, so demonstrating that the graph mirrors the process graph is partly self-referential in the trivial sense that any trace reflects the system being traced; however, the paper does not present this reflection as a validated prediction or as independent evidence of correctness. The self-citation of [4] (Sacco, Sopranzetti, Fiore, 2024) is a normal citation of prior work by two overlapping authors and is not load-bearing for the novel openEO integration, which is demonstrated against the external openeo-flood-mapper use case. The acknowledged limitations that sub-process graphs are not expanded (Section V.B) and that remote back-end provenance is only an aim ('we aim to achieve consistent and transparent provenance', Section IV.D) are completeness and correctness risks, not circularity. No pattern from the enumerated list applies: no self-definitional reduction, no fitted input called prediction, no load-bearing self-citation chain, no imported uniqueness theorem, no ansatz smuggled via citation, and no renaming of a known result. The derivation chain, such as it is, is a design-and-integration narrative rather than a formal derivation from premises, and it is self-contained against external benchmarks. Therefore the appropriate circularity score is at the low end of the 0-2 band.
Assumptions & free parameters
assumptions (3)
- domain assumption The W3C PROV data model, as implemented in yProv4WFs, is sufficiently expressive to represent all relevant aspects of openEO workflows, including user-defined functions and sub-process graphs.
- domain assumption Node-level traversal of the openEO process graph DAG by openeo-pg-parser-networkx covers all runtime activities and data dependencies.
- domain assumption The same parser instrumentation works identically on remote back-ends that use different compute engines (Dask, Airflow, etc.).
Cite this review
Pith. "Pith review of Towards Provenance-Aware Earth Observation Workflows: the openEO Case Study." pith.science (2026). https://pith.science/paper/UI5X34TL
@misc{pith2026250608597,
author = {Pith},
title = {Pith review of: Towards Provenance-Aware Earth Observation Workflows: the openEO Case Study},
year = {2026},
howpublished = {\url{https://pith.science/paper/UI5X34TL}},
note = {Machine review of arXiv:2506.08597}
}
read the original 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.
Figures
Figures from the paper (4 more)
Reference graph
Works this paper leans on
-
[1]
H. Tan, P. Yue, D. Yu, S. Boyi and Z. Cao, ”A provenance- aware method for updating Earth Observation training data,” 2022 10th International Conference on Agro-geoinformatics (Agro- Geoinformatics), 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
work page 2025
-
[3]
Pebesma, E., Wagner, W., Schramm, M., V on 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 Applic...
-
[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
arXiv 2024
-
[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
Show all 22 references
-
[9]
K., & King, R
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
2013
-
[10]
Kedron, P., & Frazier, A. E. (2022). How to improve the reproducibil- ity, replicability, and extensibility of remote sensing research. Remote Sensing, 14(21), 5471. https://doi.org/10.3390/rs14215471
2022 doi
- [11]
-
[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
2018 doi
-
[13]
Z., Soiland-Reyes, S., Sinnott, R
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
2019 doi
-
[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
2008
-
[15]
Cylc: A Workflow Engine for Cycling Systems
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
2018
-
[16]
StreamFlow: cross-breeding cloud with HPC,
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
2021
-
[17]
J. Kumar et al., ”Provenance–aware workflow for data quality manage- ment 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/ BigData4...
2019
-
[18]
S. Fiore et al., ”A Graph Data Model-based Micro-Provenance Approach for Multi-level Provenance Exploration in End-to-End Climate Work- flows,” IEEE BigData2023, Sorrento, Italy, 2023, pp. 3332-3339. doi: https://doi.org/10.1109/BigData59044.2023.10386983
2023
-
[19]
P., Pietroniro, A., Vionnet, V ., Casson, D
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 snow- fed riv...
-
[20]
Cuevas-Vicentt ´ın, V ., Dey, S., K¨ohler, S. et al. Scientific Workflows and Provenance: Introduction and Research Opportunities. Datenbank Spek- trum 12, 193–203 (2012). https://doi.org/10.1007/s13222-012-0100-z
2012 doi
-
[21]
A provenance model for control-flow driven scientific workflows,
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
2021
-
[22]
Sporny M. et al. JSON-LD 1.0. W3C Recommendation 16 January 2014. http://www.w3.org/TR/2014/REC-json-ld-20140116/
2014
Reviewed August 7, 2026 · model on record in the stance chip above.
Discussion (0). Sign in to comment.