Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Addition of *_calib_status "optional" ObsCore attributes to the model? #6

Open
gpdf opened this issue Mar 8, 2023 · 1 comment
Open
Labels
2.5 enhancement New feature or request

Comments

@gpdf
Copy link

gpdf commented Mar 8, 2023

The ObsCore data model contains "optional" elements of the form *_calib_status, providing more information about the level of calibration of various axes, spatial, temporal, spectral, and observable. We are likely to include these in the Rubin Observatory's ObsCore tables, basically because the overall calib_level = 1 vs. =2 distinction doesn't adequately capture the way we create the planned data products, and in particular how the observable (flux-like) axis is calibrated.

In order to maintain the connection with CAOM2, we would like to suggest that the Position, Time, Energy, and Observable objects in the CAOM2 data model each be supplemented with a string-valued calib_status attribute with multiplicity [0..1] (i.e., optional).

Looking at the language in the ObsCore standard (quoted verbatim below) it doesn't seem like the enumeration values for these attributes are sufficiently standardized to be able to force them to be explicit enumerations in CAOM.

Attribute Short title Principal Utype Suggested values Description
s_calib_status Type of calibration along the spatial axis 1 Char.SpatialAxis .calibrationStatus uncalibrated, raw, calibrated A string to encode the calibration status along the spatial axis (astrometry). Possible values could be {uncalibrated, raw, calibrated} and correspond to the Utype Char.SpatialAxis.calibrationStatus. For some observations, only the pointing position is provided (s_calib_status =”uncalibrated”). Some other may have a raw linear relationship between the pixel coordinates and the world coordinates (s_calib_status = ”raw”).
t_calib_status Type of time coordinate calibration 0 Char.TimeAxis .calibrationStatus uncalibrated, calibrated, raw, relative This parameter gives the status of time axis calibration. This is especially useful for time series. Possible values are principally {uncalibrated, calibrated, raw, relative}. This may be extended for specific time domain collections.
em_calib_status Type of spectral coord calibration 0 Char.SpectralAxis .calibrationStatus uncalibrated, calibrated, relative, absolute This attribute of the spectral axis indicates the status of the data in terms of spectral calibration. Possible values are defined in the Characterisation Data Model and belong to {uncalibrated, calibrated, relative, absolute}.
o_calib_status Type of calibration for the observable coordinate 1 Char.ObservableAxis .calibrationStatus absolute, relative, normalized, any This describes the calibration applied on the Flux observed (or other observable quantity). It is a string to be selected in {absolute, relative, normalized, any} as defined in the SSA specification (Tody, Dolensky and al. 2012) in section 4.1.2.10. This list can be extended or updated for instance using an extension mechanism similar to the definition of new UCDs in the IVOA process, following the feedback from implementations of ObsTAP services.

The following characteristics are in common for all four attributes:

Attribute Value
Datatype adql:VARCHAR / Enum string
Units NULL
UCD meta.code.qual
Mandatory 0
Index 0 (except for o_calib_status, where it's "TBD")
Std 1
@pdowler pdowler added the enhancement New feature or request label May 24, 2024
@pdowler
Copy link
Member

pdowler commented May 24, 2024

I feel like o_ucd, calibrarion_level, and o_calib_status are all sort of describing similar things (well, maybe level is a lot less specific). Is it not the case that o_ucd could include qualifiers that would express those suggested o_calib_status concepts? And if not, that seems like a vocabulary (UCD) problem.

Thoughts?

The axis calib statuis concepts otherwise seem good, aside from needing (at this point in the ivoa) explicit vocab support.

@pdowler pdowler transferred this issue from opencadc/caom2 Jul 5, 2024
@pdowler pdowler added the 2.5 label Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.5 enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants