{"id":"fb812b1a-5772-44dd-82cd-3519e7d1a83a","arxiv_id":"2501.00544","paper_version":1,"verdict":"ACCEPT","confidence":"HIGH","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Rubin Observatory has implemented an SIAv2 image access service that queries the Data Butler directly, with some metadata gaps for coadded images.","lead":"This paper describes a new online service that lets astronomers query Rubin Observatory's image data using the standard IVOA SIAv2 protocol by talking directly to the Data Butler storage system. It is a practical infrastructure report for anyone building data access services for large astronomical surveys.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 'ready to be used with commissioning data' claim is too broad: the paper's own Section 4 shows coadds cannot be served with full SIAv2 metadata, so the central claim holds only for single-visit datasets unless explicitly scoped.","rationale":"The reader correctly identified the coadd metadata gap as the weakest assumption. My stress-test agrees but pushes on how it affects the paper's central claim. The paper's conclusion says the service is 'ready to be used with commissioning data' without qualification. Yet Section 4 shows the service cannot answer standard SIAv2 queries for an entire product class, namely coadds. Since Rubin data holdings include coadds, and since commissioning may produce or reference coadds, the unqualified 'ready' claim is stronger than the evidence supports. This is not a question of external consensus or hidden misconduct; it is an internal mismatch between a stated limitation and the conclusion. A conditional verdict is appropriate: accept the engineering report, but require the authors to either scope the readiness claim to supported product types or demonstrate that commissioning data are coadd-free and that coadd queries are not part of the acceptance criteria. The proposed concrete test would settle whether the mismatch is material by checking actual service behavior on coadd queries against an independent ObsCore/TAP comparison.","tokens_in":3304,"tokens_out":5624,"duration_ms":61088,"concrete_test":"Run a POS-restricted SIAv2 query against the deployed DP02 service aimed at a known coadd footprint, including an explicit DPSUBTYPE=deep_coadd or equivalent dataset-type filter, and inspect the returned VOTable for the instrument, t_min/t_max, and exptime columns. Independently run the same query over the existing ObsCore/TAP view and compare row counts and column completeness. If the SIAv2 response omits or nulls mandatory fields for coadd rows, or silently excludes coadds, the 'ready' claim must be qualified to single-visit datasets.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim is that the SIAv2 service is implemented and ready for commissioning data. The load-bearing condition is that the Butler registry contains enough per-dataset metadata to populate the SIAv2 response for every product type the service exposes. Section 4 documents that this condition currently fails for coadds: instrument is absent from the coadd dataset type (4.1), exposure time is not stored for coadds (4.2), and observing dates are lost (4.3). Because SIAv2 supports queries and response columns for INSTRUMENT, TIME, and EXPTIME, a coadd query in a mixed-instrument repository cannot be answered in a fully standard-conformant way. The authors acknowledge these gaps, but the conclusion still states that the service is ready without scoping that statement to non-coadd products or verifying that commissioning data will be coadd-free. If the intended claim is 'ready for single-visit commissioning images', the current wording overstates coverage; if the claim is 'ready for Rubin data products generally', it is false. This is an internal mismatch between the conclusion and the documented limitations, not a disagreement with external consensus.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":3486,"tokens_out":3910,"duration_ms":41825,"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":[{"comment":"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":"Section 3 and Section 4.1-4.3"},{"comment":"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.","section":"Section 3 and Section 5"}],"minor_comments":[{"comment":"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":"Section 4.4"},{"comment":"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.","section":"Section 3"},{"comment":"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.","section":"Figure 1"}],"recommendation":"major_revision","confidential_remarks":"This is a short engineering report rather than a research breakthrough, but it is the kind of practical interoperability work that is valuable for the VO community and fits a software-focused journal. The main risk is that the 'ready for commissioning data' claim will be read as full SIAv2 compliance for all Rubin data products, which the paper's own Section 4 contradicts. I do not see a fatal flaw; a revision that scopes the claim and provides even one concrete query/response example would remove my concern. The self-citations to prior Butler and ObsCore work are appropriate and not circular."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague—\n\nThe short version: this is a solid engineering status report, not a scientific result, and the main new thing—a real SIAv2 service that queries the Butler directly, without an ObsCore export—is worth knowing about if you work on survey data access. The paper's own Section 4 undercuts part of its headline claim, though; more on that below.\n\nWhat is actually new: the dax_obscore library, which cleanly separates SIAv2 parameter parsing from the service layer, and the FastAPI service deployment on Rubin's platform. The command-line tool is a nice bonus. The authors also give an honest list of the Butler data model mismatches with SIAv2—instrument, exposure time, and observing dates are all missing for coadds. That kind of concrete reporting is useful to the IVOA community.\n\nWhere I disagree with the stress-test note is only in degree. It says the 'ready to be used with commissioning data' claim is too broad. I think that's right: a reader who asks SIAv2 queries against coadds in a mixed-instrument repository cannot get standard-conformant answers, since INSTRUMENT, TIME, and EXPTIME are either absent or non-derivable. The authors acknowledge this but the conclusion still says 'ready' without scoping it. That's a wording problem, not a fatal flaw, and it should be fixed in revision. The honesty of Section 4 actually makes the paper stronger than most status reports.\n\nThe bigger gap, also noted by the reader, is that there is no quantitative validation or performance benchmark. I don't consider that a reason to reject—conference papers of this type often do not have it—but it does mean the 'it works' claim is based on deployment status, not on measured query correctness or speed.\n\nThe citation pattern is fine. Self-citations to the Butler and prior ObsCore work are contextual.\n\nBottom line: this paper deserves a serious referee. I'd recommend acceptance with a minor revision that scopes the 'ready' claim to non-coadd products and explicitly states that coadd queries are partial until provenance-derived metadata lands. If I were working on SIAv2 or Butler integration, I'd cite it.","headline":"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.","tokens_in":4029,"tokens_out":2246,"would_cite":true,"duration_ms":21455,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The Rubin Data Butler can now serve IVOA SIAv2 image queries directly, without maintaining a separate ObsCore export.","keywords":["SIAv2","Data Butler","Rubin Observatory","IVOA","ObsCore","VOTable","astronomical data services","image access"],"falsifier":"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.","tokens_in":3156,"feed_emoji":"🔭","tokens_out":5693,"duration_ms":48344,"temperature":0.7,"pith_summary":"This paper reports that implementing the IVOA Simple Image Access version 2 (SIAv2) protocol directly on Rubin Observatory's Data Butler was relatively simple. The authors have deployed a FastAPI service that translates SIAv2 query parameters into Butler queries and returns standardized VOTable results, and they say it is ready for commissioning data. The point of the work is to avoid the deployment constraints of the previous ObsCore export or live-sync approach, such as requiring pgsphere and rebuilding tables when configuration changes. A command-line tool is also included so that anyone can run SIAv2-style queries against any Butler repository locally.","feed_headline":"Data Butler now serves standard SIAv2 image queries directly","feed_subtitle":"Astronomers can query commissioning-era images through the standard SIAv2 protocol, no ObsCore export needed.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines the SIAv2 protocol and its query parameters that this service implements.","marker":"(Dowler et al. 2015)"},{"why":"Describes the Rubin Data Butler, the registry and datastore that the service queries.","marker":"(Jenness et al. 2022)"},{"why":"Describes the existing ObsCore-as-view approach that motivates the direct SIAv2 service.","marker":"(Salnikov 2022)"},{"why":"Describes the remote client/server Butler mode that the service transparently supports.","marker":"(Jenness et al. 2024)"},{"why":"Documents the SIAv2-over-Butler FastAPI service, the deployed implementation this paper reports.","marker":"(Voutsinas & Jenness 2024)"},{"why":"Describes Felis, which defines the response table schema for consistency.","marker":"(McCormick et al. 2025)"}],"fun_headline_variants":["SIAv2 service now runs directly on Data Butler","Rubin's Data Butler speaks SIAv2 natively","Image queries go straight to Data Butler via SIAv2","No ObsCore needed: SIAv2 meets Butler metadata","Direct SIAv2 access to Rubin's image registry"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["SIAv2 service now runs directly on Data Butler","Rubin's Data Butler speaks SIAv2 natively","Image queries go straight to Data Butler via SIAv2","No ObsCore needed: SIAv2 meets Butler metadata","Direct SIAv2 access to Rubin's image registry"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000347,"raw_usage":{"total_tokens":1839,"prompt_tokens":826,"completion_tokens":1013,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":442,"completion_tokens_details":{"reasoning_tokens":929}},"tokens_in":442,"tokens_out":1013,"duration_ms":9773,"temperature":1.0,"reasoning_tokens":929,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T22:47:05.467668+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"2022, ObsCore as a View of Butler Registry Tables","cited_arxiv_id":null,"evidence_quote":"Describes the existing ObsCore-as-view approach that motivates the direct SIAv2 service."},{"cited_title":"H., Bosch , J","cited_arxiv_id":null,"evidence_quote":"Describes the remote client/server Butler mode that the service transparently supports."},{"cited_title":"2024, SIAv2 over Butler FastAPI service","cited_arxiv_id":null,"evidence_quote":"Documents the SIAv2-over-Butler FastAPI service, the deployed implementation this paper reports."},{"cited_title":"Using Felis to Represent the Semantics and Metadata of Astronomical Data Catalogs","cited_arxiv_id":"2412.09721","evidence_quote":"Describes Felis, which defines the response table schema for consistency."}],"review_version":1}