ObsCore and extensions

[BONNAREL FRANCOIS gmail]

Dear Pat,
My personal "retired-person" and nonetheless co-editor of the Radio 
extension PR.
Other co-editors Mark Kettenis and Mireille will add their feelings
Le 06/01/2025 à 21:02, Patrick Dowler via dm a écrit :
> At the last interOp and while comparing the radio extension to
> CAOM-2.4 and some new features in WD-CAOM-2.5, it became increasingly
> clear that some of the proposed fields for the radio extension are
> more generally applicable and in my opinion should be promoted to
> "core". I kind of volunteered to write down the details of that, so
> here it is that proposal:
Basically, I think your are right. Many of the terms proposed in the 
radio extension could be interesting in the
basic ObsCore. However your proposal tend to delay any work done within 
the scope of the Radio extension project
until the new ObsCore is ready. The IVOA history shows that generally a  
new version of a specification takes a lot
of time to become a recommendation. So I suggest another solution 
below.  Before that, a few comments on your suggestions for the terms
>
> ** core **
> s_resolution_min
> s_resolution_max
> s_fov_min
I am probably OK, although I am not sure most optical astronomers will 
have frequent use of this.
> s_fov_max: I still feel the existing s_fov is already the same as
> s_fov_max and not a representative value; it is nominally the size of
> the s_region
This could be the choice of some projects. But the idea in the group was 
that the choice for the representative value
belongs to the project . It is what they would like to be considered as 
a  typical value for discovery purposes.
> t_exp_min
> t_exp_max
It could be useful for time series outside the radio domain,  right. 
It's in the proposal for time extension too. I am  not sure if it's 
useful outside time series. I let Mireille and other Time extension 
authors comment on this
> t_exp_mean: In CAOM exposure is already the mean exposure time per
> pixel and I feel strongly that the existing ObsCore.t_exptime is
> already the same thing (well, it suggests "median exposure time per
> pixel" which I think I may have contributed, but median breaks down in
> some common nearly degenerate cases and is less useful than mean; we
> may need to clarify the definition in ObsCore
Yes you are right. t_exptime makes sense "per se" for "one shot" 
measurements. So the discussion is still going on on this one both in 
Time extension and Radio extension. Is t_exp_mean the same thing as 
t_exptime or are they different concepts.
> f_resolution: absolute spectral resolution is useful, but this should
> be named em_resolution
em_* terms  were reserved to attributes in wavelength quantity. So 
that's why if we want some resolution in frequency a new term has to be 
proposed. if f_resolution has a constant value inside the dataset (usual 
case in radio) then the resolution  in wavelength (em_resolution ?)  
will be varying.
>
> ** radio extension **
> s_maxiumum_angular_scale - I have been convinced by radio people that
> maximum_recoverable_scale is more explicit and a better term for this
Some others proposed us angular_scale at the beginning of the project. 
This could be chosen after a discussion among radio astronomers in the RIG
> uv_distance_min
> uv_distance_max
> uv_distribution_ecc
> uv_distribution_fill
>
> Questions:
> 1. How does this impact the time extension?
> 2. How does this impact the high energy extension?
As far as I know the t_exp_* attributes are also discussed in the time 
extension.
For the high energy extension there is still a lot to discuss on how we 
expose event list data or advanced data products to ObsCore. See Ian 
Evans presentation at last interop, for example.
That's one of the reasons I think that moving all the new terms to the 
root ObsCore could take more time than you expect.

Moreover I think a new version of ObsCore could require to have a VODML 
version of it (see Paul Harrisson criticism) and to extend both the 
characterisation class and the instrumental provenance consistently.
>
> Work:
> 1. ObsCore needs to be ported to ivoatex (from docx?) and included in ivoa-std
> 2. I can set aside time necessary to write the the changes for WD-ObsCore-1.2
Starting a new version of ObsCore has to be done for sure. But as I 
think it will take time and radio astronomers need the new terms sooner 
after discussing with the extension co-editors (MK+ML) I propose to 
publish the current extension as an "endorsed note". With this status it 
could be replaced easily in the future by a new version of ObsCore 
containing root terms and the extension(s).
Cheers
François
>
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada