Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

Using Felis to Represent the Semantics and Metadata of Astronomical Data Catalogs

T0 review · 3 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Felis is a YAML-based data model that lets the Rubin Observatory define, validate, and publish its catalog schemas from a single source.

desk verdict A solid, honest software description paper for Felis, with the TAP_SCHEMA mapping under-specified but public code and real deployment carrying the weight. read the letter →

arxiv 2412.09721 v1 pith:QUPDWLIM submitted 2024-12-12 astro-ph.IM cs.DL

Jeremy McCormick , Gregory P. Dubois-Felsmann , Andrei Salnikov , Brian Van Klaveren , Tim Jenness This is my paper · ORCID
classification astro-ph.IMcs.DL
keywords FelisdatadescriptionlanguagecatalogmetadataTAP_SCHEMAIVOATAPYAMLPydanticRubinObservatory
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that Felis, a YAML-based data description language and Python toolset, can serve as the authoritative definition of a scientific data catalog, including semantic metadata that ordinary DDL cannot express. It argues that a single validated Felis model can generate the database DDL and populate the IVOA TAP_SCHEMA tables used by the Rubin Science Platform, making the schema uniformly defined and checked before publication. This matters because astronomy catalogs are consumed through TAP services, and without such a description, units, UCDs, constraints, and column relationships live only in documentation or in the database, where they can drift out of sync.

What carries the argument

The carrying mechanism is the Felis schema model: a hierarchy of Pydantic BaseModel classes, named Schema, Table, Column, Constraint, and Index, expressed in YAML. Pydantic's Field declarations enforce types, defaults, and required presence, while custom Python validator functions enforce business rules such as unique table names; a failed validation blocks loading. From the validated in-memory model, extension modules generate SQL DDL or TAP_SCHEMA insert statements, and the same Felis datatypes carry mappings to PostgreSQL, MySQL, and VOTable types.

What would settle it

Compare every table, column, unit, UCD, constraint, and index in the public Rubin TAP_SCHEMA served by the Rubin Science Platform against the Felis YAML definitions in the SDM Schemas repository; a single column whose unit, UCD, or constraint differs from the YAML would show that Felis is not in fact the single source of truth.

Watch

Extended reading notes

Core claim

Felis is a data description language whose core is a Pydantic data model. Every schema object is a Python class inheriting from Pydantic's BaseModel, and the YAML files are validated on load by Field rules and by extra 'business rule' validators that catch problems such as duplicate table names. Felis defines its own datatype system, mapping types like int and string to target SQL dialects and to VOTable types, and from a validated model it can generate DDL for PostgreSQL and MySQL or insert statements that populate TAP_SCHEMA. The paper reports that the Rubin Science Data Model Schemas are maintained as Felis files in a Git repository, versioned with Git tags, checked in CI, and used by the Rubin Science Platform's TAP services and SIAv2.

Load-bearing premise

The whole approach rests on the assumption that a Felis YAML file, validated by Pydantic rules and custom checks, captures every semantically important detail of the catalog, so that generating DDL and TAP_SCHEMA from it cannot drop or distort information.

Editorial extensions

If this is right

  • Rubin gets a single source of truth for each public catalog: the YAML file is the schema, and DDL and TAP_SCHEMA are derived artifacts.
  • Schema editing becomes reviewable: because schemas live in Git with tags and CI validation, proposed changes are checked before they reach the database.
  • Any consumer that can read VOTable metadata can rely on TAP_SCHEMA being consistent with the published schema, since both come from the same validated model.
  • Felis's planned migration generation and tabular-data conversion would let the schema definition propagate to both schema versions and data files.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the same pattern is adopted by other survey projects, a single YAML catalog description could become a common interchange format for catalog semantics, not just a Rubin internal tool.
  • A concrete audit test would be to parse an existing Rubin TAP_SCHEMA back into Felis and diff it against the source YAML; any mismatch would reveal whether the mapping is lossless.
  • Because Felis's datatype set is small and explicitly mapped, adding a new SQL dialect or a non-relational target would be localized to the type-mapping layer, potentially lowering the cost of multi-platform catalog publication.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper describes Felis, a YAML-based data description language and Python toolset developed by the Vera C. Rubin Observatory Data Management team. Felis defines catalog structure and semantic metadata (units, UCDs, descriptions, constraints, relationships) using a Pydantic-based data model, validates schemas upon loading, generates DDL for PostgreSQL and MySQL, and populates IVOA TAP_SCHEMA tables for the Rubin Science Platform's TAP services. The paper also reports on its use for the Rubin SDM Schemas, CI-based validation via GitHub workflows, an online schema browser, and the SIAv2 service.

Significance. If the paper's claims hold, Felis is a genuinely useful contribution to astronomical data management: it addresses the well-known limitation that DDL cannot express semantic metadata, and it offers a single-source-of-truth approach that has been deployed operationally at Rubin. The public GitHub repository and the real-world adoption for the Rubin SDM Schemas and SIAv2 are concrete strengths. The paper does not provide a formal proof of semantic losslessness or a complete test suite, but the main weakness is not the absence of proofs—it is the lack of detail on two load-bearing parts of the pipeline: the actual validation rules and the YAML-to-TAP_SCHEMA mapping logic.

major comments (3)
  1. [3. Schema Validation] The description of validation is too vague to support the paper's central claim that Felis ensures schema correctness. Only one example of a 'business rule' is given (unique table names), and the paper does not state whether foreign-key referential integrity is checked, whether the Felis datatype mappings cover all target database types, or whether values such as UCDs and units are validated against controlled vocabularies. Please list the actual set of enforced validation rules, or explicitly state which semantic aspects are stored without validation.
  2. [6. DDL Generation] The paper states that Felis 'may also populate a TAP_SCHEMA database' but gives no description of the mapping logic from the Felis YAML model to the TAP_SCHEMA tables. Without this, the reader cannot assess whether the generated TAP_SCHEMA faithfully preserves the input semantics, which is the key promise of the 'single source of truth' claim. Please include a description of the mapping (or a reference to a documentation page), and report any conformance tests or validation checks against the IVOA TAP_SCHEMA constraints.
  3. [Entire manuscript] The paper lacks reproduction instructions: it does not specify versions of Felis and Pydantic, does not give a concrete example invocation (e.g., how to run 'felis' on an example YAML file), and does not reference a test suite or CI status in the repository. For a software-description paper, providing a short 'getting started' example or a link to a documented demonstration would materially increase the verifiability of the claims.
minor comments (5)
  1. [4. Using the Python API] The example uses the URI 'resource://...' without any explanation of how this scheme is resolved; consider replacing it with a concrete example that a reader can try.
  2. [2. Schema Data Model] The paper references 'Figure 1. ERD diagram of the schema data model' but the figure is not included in the text submitted for review; please ensure the figure is present and legible in the final version.
  3. [5. Felis Data Types] A small table mapping the most common Felis types (boolean, int, char, string, etc.) to PostgreSQL, MySQL, and VOTable types would make Section 5 concrete and more useful.
  4. [1. Introduction] The author list and affiliations contain a typo: 'V era' should be 'Vera' (in the first affiliation and the acknowledgment).
  5. [References] The reference to Jenness et al. 2025 is incomplete ('vol. TBD', '999 TBD'); please update with the full bibliographic data if available at the time of publication.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: Felis is a software/format description with no derived predictions or fitted inputs.

full rationale

This paper contains no derivation chain, no fitted parameters, no predicted quantities, and no equations. Felis is a schema-definition tool: it validates YAML metadata with a Pydantic model and uses that model to generate DDL and TAP_SCHEMA output. The claim that the YAML model is a single source of truth is a software-architecture claim, not a result derived from that same model; the validation rules and later DDL/TAP_SCHEMA generation are separate code paths whose correctness is evidenced by the public repository and the actual Rubin deployment. Self-citations (e.g., Rubin SDM Schemas, the SIAv2 service) are used as examples of deployment, not as load-bearing justification for a mathematical or empirical claim. The paper's acknowledged limitations, such as unstated details of TAP_SCHEMA mapping and validation coverage, are correctness/fidelity risks rather than circular reasoning: an incomplete validator or mapping would be a quality defect, not a case of the conclusion being equivalent to its premises. No circular step can be identified from the manuscript text.

Assumptions & free parameters 0 free parameters · 2 assumptions · 0 invented entities

Felis is software, not a physical theory. It introduces no new physical entities or fitted parameters. Its design relies on domain standards like TAP and UCD, and on the Python Pydantic library as a validation engine.

assumptions (2)
  • domain assumption The IVOA TAP and UCD standards are the correct target for representing catalog semantics.
    The entire tool is built around generating TAP_SCHEMA and UCD values, so the paper assumes these standards capture what users need.
  • domain assumption Pydantic's BaseModel validation is expressive enough to encode all required business rules.
    Section 3 says business rules are enforced with Python validator functions, but no completeness proof is given.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Using Felis to Represent the Semantics and Metadata of Astronomical Data Catalogs." pith.science (2026). https://pith.science/paper/QUPDWLIM

@misc{pith2026241209721,
  author       = {Pith},
  title        = {Pith review of: Using Felis to Represent the Semantics and Metadata of Astronomical Data Catalogs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QUPDWLIM}},
  note         = {Machine review of arXiv:2412.09721}
}
read the original abstract

The Data Management team of the Vera C. Rubin Observatory has developed a data description language and toolset, Felis, for defining the semantics and metadata of its public-facing data catalogs. Felis uses a rich Pydantic data model for describing and validating catalog metadata, expressed as a human-readable and editable YAML format. Felis also provides a Python library and command line interface for working with these data models. The metadata is used to populate the TAP_SCHEMA tables for the IVOA TAP services utilized by the Rubin Science Platform (RSP). Felis's current capabilities will be discussed along with some future plans.

Figures

Figures reproduced from arXiv: 2412.09721 by the authors.

Figure 1
Figure 1. ERD diagram of the schema data model. All objects in the schema have a set of common attributes, including a name, identifier, and description. The name attribute is required and corresponds to the name of the object in the target database. The description is an optional, human-readable description of the object. The identifier provides a way to uniquely identify the object within the schema and is primarily used fo… view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Implementing SIAv2 Over Rubin Observatory's Data Butler

    astro-ph.IM 2024-12 accept novelty 4.0 of 10

    Rubin Observatory has implemented an SIAv2 image access service that queries the Data Butler directly, with some metadata gaps for coadded images.

Reference graph

Works this paper leans on

6 extracted references · 4 canonical work pages · cited by 1 Pith paper

  1. [1]

    arXiv:2206.14220 , ://doi.org/10.3847/1538-4357/ac7c74

    Astropy Collaboration 2022, , 935, 167. arXiv:2206.14220 , ://doi.org/10.3847/1538-4357/ac7c74

    arXiv 2022

  2. [2]

    2023, UCD1+ controlled vocabulary - Updated List of Terms Version 1.5 Version 1.5 , IVOA Endorsed Note 25 January 2023

    Cecconi , B., et al. 2023, UCD1+ controlled vocabulary - Updated List of Terms Version 1.5 Version 1.5 , IVOA Endorsed Note 25 January 2023. ://doi.org/10.5479/ADS/bib/2023ivoa.spec.0125C

    work page doi:10.5479/ads/bib/2023ivoa.spec.0125c 2023

  3. [3]

    2019, Table Access Protocol Version 1.1 , IVOA Recommendation 27 September 2019

    Dowler , P., Rixon , G., Tody , D., & Demleitner , M. 2019, Table Access Protocol Version 1.1 , IVOA Recommendation 27 September 2019. ://doi.org/10.5479/ADS/bib/2019ivoa.spec.0927D

    work page doi:10.5479/ads/bib/2019ivoa.spec.0927d 2019

  4. [4]

    2019, ApJ, 873, 111

    Ivezi \'c , Z ., et al. 2019, ApJ, 873, 111. arXiv:0805.2366 , ://doi.org/10.3847/1538-4357/ab042c

    arXiv 2019

  5. [5]

    P., & Salnikov, A

    Jenness, T., Voutsinas, S., Dubois-Felsmann, G. P., & Salnikov, A. 2025, in ADASS XXXIV, edited by A. DeMarco, & J. Said (San Francisco: ASP), vol. TBD of ASP Conf. Ser., 999 TBD

    work page 2025

  6. [6]

    2023, Data Products Definition Document

    Juri\' c , M., et al. 2023, Data Products Definition Document . Vera C. Rubin Observatory LSE-163 , ://lse-163.lsst.io/

    work page 2023

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.