REVIEW 2 major objections 3 minor 8 references
Implementing SIAv2 Over Rubin Observatory's Data Butler
T0 review · 2 major / 3 minor · reviewed 2026-08-10 · deepseek-v4-flash
Pith's one-line read The Rubin Data Butler can now serve IVOA SIAv2 image queries directly, without maintaining a separate ObsCore export.
desk verdict A credible SIAv2-over-Butler engineering report whose 'ready for commissioning data' claim needs scoping to single-visit products given the discussed coadd metadata gaps. 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 object is dax_obscore, a standalone SIAv2-to-Butler query handler. It takes raw SIAv2 parameters and a repository-specific configuration, translates them into Butler registry queries, runs them against either the direct or remote Butler, and packages the dataset references into an ObsCore-schema VOTable via Astropy. A thin FastAPI service forwards HTTP queries to this layer, and the same layer exposes a command-line interface for local use. This separation is what makes the implementation simple: the protocol logic is decoupled from the web service and can be tested and reused independently.
What would settle it
Run an SIAv2 query with POS, TIME, and EXPTIME against a Butler repository that contains both individual exposures and deep coadds. If the returned coadd records have empty or incorrect values for those mandatory columns, the paper's claim that the service is ready for full SIAv2 use fails for coadds until Butler provenance support is added.
Extended reading notes
Core claim
The central claim is that a standardized SIAv2 interface can sit directly on top of the Data Butler's registry and datastore. The dax_obscore layer parses SIAv2 parameters (MAXREC, INSTRUMENT, POS, TIME, BAND, EXPTIME, CALIB), converts them into Butler queries, and returns an Astropy VOTable whose schema is defined by a Felis data model. The service works transparently with both the direct Butler and the new client/server remote Butler. The authors state that the process was relatively simple and that the deployed service is ready to be used with commissioning data. They also document real metadata mismatches: coadds currently lack instrument, exposure time, and observing dates in the registry, so those SIAv2 fields cannot be correctly populated for coadded products until provenance and derived metadata support is added.
Load-bearing premise
The service can fully respond to SIAv2 queries only if the Butler registry already stores the per-dataset metadata that SIAv2 requires; the paper itself shows this is currently false for coadded images, which lack instrument, exposure time, and observing dates.
Editorial extensions
If this is right
- SIAv2 image queries can be served directly from any Butler repository, so evolving datasets such as nightly prompt products do not require a static ObsCore export.
- Configuration changes to the query layer take effect with a service restart rather than a full table rebuild.
- The command-line interface lets users learn SIAv2 parameters and test queries locally against any Butler repository.
- Researchers can query commissioning-era Rubin images through the same IVOA SIAv2 endpoint once commissioning data are loaded.
- A future DPSUBTYPE extension could let users filter directly by Butler dataset type, such as visit_image or deep_coadd.
Reading between the lines
- If the metadata gaps for coadds are closed by provenance tracking, the same service should be able to answer POS, TIME, and EXPTIME queries over coadds without changing the SIAv2 layer, only the Butler registry content.
- The layered design suggests a route to other IVOA query protocols, such as cone search or TAP, by writing additional parameter-to-Butler translators that reuse the same service shell.
- A direct comparison of SIAv2 responses against the ObsCore/TAP view over the same repository would quantify whether the two access paths return identical record sets, which would be a useful commissioning-time test.
- The DPSUBTYPE proposal implicitly gives users a way to express science-case queries such as 'give me deep coadds' that SIAv2 itself does not standardize; if adopted, it could motivate a broader IVOA discussion about dataset-type filtering.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper reports on the design and deployment of a Simple Image Access version 2 (SIAv2) service that queries the Rubin Observatory Data Butler directly, without maintaining a separate ObsCore export or view. The implementation is split into a reusable Python library (dax_obscore) that parses SIAv2 parameters and translates them into Butler queries, and a FastAPI service that exposes these queries through the Rubin Science Platform. The paper lists the currently supported SIAv2 parameters (MAXREC, INSTRUMENT, POS, TIME, BAND, EXPTIME, CALIB), describes the deployment status as ready for commissioning data, and identifies metadata mismatches between the Butler data model and SIAv2, especially for coadded images (missing instrument, exposure time, and observing dates). The authors conclude that implementing SIAv2 over the Butler was relatively simple and that the service is ready for use.
Significance. If the reported implementation works, it provides a useful engineering path for serving standard image-access queries directly on a scientific data repository, avoiding the operational overhead of a maintained ObsCore view. The paper is honest in acknowledging that coadd metadata are incomplete, and the separation of the dax_obscore library from the service is a good design that supports testability and reuse. The work has practical value for the Rubin Observatory and for other IVOA-compliant services considering similar direct-to-registry architectures. However, the central readiness claim is broader than what the documented limitations support, and the paper contains no concrete demonstration (query example, response excerpt, or test report) that would let a reader independently assess conformance or correctness.
major comments (2)
- [Section 3 and Section 4.1-4.3] The statement in Section 3 that the service 'is ready to be used with commissioning data' is not scoped with respect to the limitations documented in Section 4. In particular, Sections 4.1-4.3 state that coadds in the Butler lack instrument information, exposure time, and observing dates, all of which are mandatory or commonly required SIAv2 query/response fields. Consequently, a fully SIAv2-conformant response cannot be produced for coadded images, and queries such as INSTRUMENT or TIME cannot be answered correctly for those data products. The conclusion should either explicitly restrict the readiness claim to non-coadd datasets (e.g., single-visit images) or explain how queries for coadds are handled (for example, by omitting such datasets, returning nulls, or requiring dataset-type filtering). Without this scoping, the central claim overstates the current capability.
- [Section 3 and Section 5] The paper claims that implementing the service was 'relatively simple' and that the service is 'ready to be used,' but it provides no end-to-end demonstration or validation. There is no example SIAv2 query, no sample VOTable response, no comparison against an independent SIAv2 implementation, and no documented test that verifies the query semantics or the generated output schema. Adding at least one concrete example with a real or representative Butler repository (including the returned columns and how missing metadata are represented) would substantiate the readiness claim. If such examples already exist in the cited SQR-095 technical note, the paper should point to them explicitly and summarize the verification performed.
minor comments (3)
- [Section 4.4] The proposed 'DPSUBTYPE' extension is mentioned without specifying whether this is an addition to the SIAv2 standard or an LSST-specific parameter, and without giving a concrete example of how it would map to Butler dataset types. A sentence clarifying the intended namespace and semantics would help readers assess interoperability.
- [Section 3] The sentence 'Support for ID, TARGET, FACILITY, and COLLECTION are coming soon' would benefit from a brief indication of the expected timeline or whether these are part of the SIAv2 core standard rather than extensions, since some of these parameters are not in the current supported list.
- [Figure 1] The architecture diagram would be clearer if the role of the 'dax_obscore2' component were labeled with its function (parameter parsing and query translation) and if the data flow direction from the service to the Butler repository were visually distinguished from the result path.
Circularity Check
No circularity: this is an engineering status report, not a derivation, and its self-citations are contextual rather than load-bearing.
full rationale
This paper is an engineering and deployment report rather than a derivation. The central claim, that an SIAv2 service was implemented over the Data Butler and is ready for commissioning data, is an empirical status assertion supported by the described architecture: a FastAPI service forwards SIAv2 parameters to the dax_obscore library, which translates them into Butler queries and returns a VOTable. There are no fitted parameters, no quantities predicted from inputs, and no mathematical derivation chain whose conclusion is equivalent to its assumptions. The self-citations (Jenness et al. 2022 for the Butler, Jenness et al. 2024 for remote Butler, Voutsinas & Jenness 2024 for the SIAv2 service, and Salnikov 2022 for the ObsCore view) are contextual pointers to prior engineering work and are not used to prove the implementation's correctness. The documented metadata mismatches for coadds in Sections 4.1-4.3 are admitted limitations; they weaken or scope the readiness claim, but that is a correctness/completeness concern, not circularity. No equation, fitted parameter, uniqueness theorem, or ansatz is smuggled in through citations or defined in terms of the target result. The paper's own text flags the gaps, so the conclusion does not hide its conditionality. Therefore no significant circularity is present.
Assumptions & free parameters
assumptions (4)
- domain assumption The Butler registry contains sufficient information to construct ObsCore records.
- domain assumption Butler has native support for region and time queries.
- domain assumption SIAv2 query parameters can be parsed and converted to Butler queries via dax_obscore.
- domain assumption The Rubin Science Platform authentication layer is available for the service.
Cite this review
Pith. "Pith review of Implementing SIAv2 Over Rubin Observatory's Data Butler." pith.science (2026). https://pith.science/paper/HPINLAY7
@misc{pith2026250100544,
author = {Pith},
title = {Pith review of: Implementing SIAv2 Over Rubin Observatory's Data Butler},
year = {2026},
howpublished = {\url{https://pith.science/paper/HPINLAY7}},
note = {Machine review of arXiv:2501.00544}
}
read the original abstract
The IVOA Simple Image Access version 2 protocol defines an easy way to provide community access to a collection of data. At the Vera C. Rubin Observatory we currently enable ObsTAP access to our data holdings via an ObsCore export or view of our Data Butler repositories. This approach comes with some deployment constraints, such as requiring pgsphere and compatibility with our CADC TAP implementation, so recently we decided to see whether we could instead provide an SIAv2 service that talks directly to our Data Butler. Here we describe our motivation, implementation strategies, and current deployment status, as well as discussing some metadata mismatches between the Butler data models and SIAv2.
Figures
Reference graph
Works this paper leans on
-
[1]
2015, IVOA Simple Image Access Version 2.0 , IVOA Recommendation 23 December 2015
Dowler , P., Bonnarel , F., & Tody , D. 2015, IVOA Simple Image Access Version 2.0 , IVOA Recommendation 23 December 2015. ://doi.org/10.5479/ADS/bib/2015ivoa.spec.1223D
-
[2]
Jenness , T., Bosch , J. F., Salnikov , A., Lust , N. B., Pease , N. M., Gower , M., Kowalik , M., Dubois-Felsmann , G. P., Mueller , F., & Schellart , P. 2022, in Software and Cyberinfrastructure for Astronomy VII, vol. 12189 of Proc.\ SPIE, 1218911. arXiv:2206.14941 , ://doi.org/10.1117/12.2629569
arXiv 2022
-
[3]
Jenness , T., Irving , D. H., Bosch , J. F., Salnikov , A., Lust , N. B., & Allbery , R. 2024, in Software and Cyberinfrastructure for Astronomy VIII, edited by J. Ibsen , & G. Chiozzi , vol. 13101 of Proc.\ SPIE, 131013G. ://doi.org/10.1117/12.3019130
-
[4]
Louys , M., Tody , D., Dowler , P., Durand , D., Michel , L., Bonnarel , F. a., Micol , A., & IVOA DataModel Working Group 2017, Observation Data Model Core Components, its Implementation in the Table Access Protocol Version 1.1 , IVOA Recommendation 09 May 2017. ://doi.org/10.5479/ADS/bib/2017ivoa.spec.0509L
-
[5]
Using Felis to Represent the Semantics and Metadata of Astronomical Data Catalogs
McCormick, J., Dubois-Felsmann, G. P., Salnikov, A., van Klaveren , B., & Jenness, T. 2025, in ADASS XXXIV, edited by A. DeMarco, & J. Said (San Francisco: ASP), vol. TBD of ASP Conf. Ser., 999 TBD. ://doi.org/10.48550/arXiv.2412.09721
work page Pith review arXiv doi:10.48550/arxiv.2412.09721 2025
-
[6]
2023, in ADASS XXXII, edited by S
Mueller, F., et al. 2023, in ADASS XXXII, edited by S. Gaudet , S. Gwyn , P. Dowler , D. Bohlender , & A. Hincks (San Francisco: ASP), vol. TBD of ASP Conf. Ser., 999 TBD. ://dmtn-243.lsst.io
work page 2023
-
[7]
2022, ObsCore as a View of Butler Registry Tables
Salnikov, A. 2022, ObsCore as a View of Butler Registry Tables . Vera C. Rubin Observatory Data Management Technical Note DMTN-236 , ://dmtn-236.lsst.io/
work page 2022
-
[8]
2024, SIAv2 over Butler FastAPI service
Voutsinas, S., & Jenness, T. 2024, SIAv2 over Butler FastAPI service . Vera C. Rubin Observatory SQuaRE Technical Note SQR-095 , ://sqr-095.lsst.io/
work page 2024
Reviewed August 10, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.