You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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 overallcalib_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
, andObservable
objects in the CAOM2 data model each be supplemented with a string-valuedcalib_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.
s_calib_status
t_calib_status
em_calib_status
o_calib_status
The following characteristics are in common for all four attributes:
meta.code.qual
o_calib_status
, where it's "TBD")The text was updated successfully, but these errors were encountered: