Open gpdf opened 1 year ago
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")