Obscore radio extension : instrumental details

[BONNAREL FRANCOIS]

Dear all,

A couple of monthes ago, after the last release of the Obscore extension 
draft by the Tucson interop a couple of emails adressed the instrumental 
details issue

here is a compilation (also available now on github and on the ivoa twiki)

>
>       instrumentation details
>
> Another somewhat questionable example is use case 1.10. The minimum 
> number of antennas for a "good" observation really is 
> instrument-specific and the maximum distance between antennas really 
> is just a very poor way of expressing a resolution or uv-coverage 
> constraint for which we already have columns. So unless someone can 
> come up with a scientific use case for these parameters, I think they 
> should be dropped from the extension.
>
> --MarkKettenis 
> <https://wiki.ivoa.net/twiki/bin/view/IVOA/MarkKettenis>2023-11-10
>
> Apologies that I have not been following this in detail but whilst I 
> agree with Mark that 1.10 is not a realistic use case, selection by uv 
> coverage is, but just the number of antennas and extrema of baseline 
> lengths is not enough. On the other hand, often all archives provide 
> is baseline length (or even just antenna positions), frequency, 
> pointing direction and observation duration. Metrics related to uv 
> coverage density can then easily be calculated (as in the L5 and L80 
> etc. metrics in the ALMA archive) but I don't know if this is commonly 
> seachable directly for any archive. So it is not just a matter of what 
> is commonly searched for, but also what archives provide and how much 
> there can be an interface to convert the latter to the former. 
> --AnitaRichards 
> <https://wiki.ivoa.net/twiki/bin/view/IVOA/AnitaRichards>2023-11-10
>
> The columns theDaCHS 
> <https://wiki.ivoa.net/twiki/bin/view/IVOA/DaCHS>extension now offers 
> are f_resolution, instrument_ant_diameter, instrument_ant_max_dist, 
> instrument_ant_min_dist, instrument_ant_number, instrument_feed, 
> obs_publisher_did, s_fov_max, s_fov_min, s_maximum_angular_scale, 
> s_resolution_max, s_resolution_min, scan_mode, t_exp_max, t_exp_mean, 
> t_exp_min, tracking_mode, uv_distance_max, uv_distance_min, 
> uv_distribution_ecc, uv_distribution_fill
>
> (select column_name from tap_schema.columns where 
> table_name='ivoa.obs_radio' order by column_name)
>
> This doesn't mean I'm convinced all of them should be in. But it does 
> mean that I'm pretty sure all others should go from table 1; in 
> particular, the "viaDataLink 
> <https://wiki.ivoa.net/twiki/bin/view/IVOA/DataLink>" things I think 
> are just confusing in there.
>
> --MarkusDemleitner 
> <https://wiki.ivoa.net/twiki/bin/view/IVOA/MarkusDemleitner>2023-12-11
>
> I raised my concerns about the instrument_* columns during theInterOp 
> <https://wiki.ivoa.net/twiki/bin/edit/IVOA/InterOp?topicparent=IVOA.ObsCoreExtensionForRadioData;nowysiwyg=0>. 
> Those really are instrument specific and therefore not very useful in 
> generic queries one would issue to multiple TAP services. It may make 
> more sense to provide this information in an observatory specific 
> table (see for example the presentation by Greg Sleap on how the MWA 
> presents information like this).
>
> --MarkKettenis 
> <https://wiki.ivoa.net/twiki/bin/view/IVOA/MarkKettenis>2023-12-13
>
> - Given thatObsCore 
> <https://wiki.ivoa.net/twiki/bin/view/IVOA/ObsCore>is meant for data 
> discovery, any instrument specific details should be removed as much 
> as possible, to make sure that a cross-ObsTAP-service-query will Just 
> Work ™. That there may be a (defined) mechanism to get to instrument 
> specifics would be important to have - e.g. for visibility data te 
> u,v-plane characterisation. These could be standard extensions 
> ofObsCore <https://wiki.ivoa.net/twiki/bin/view/IVOA/ObsCore>but could 
> live outside theObsCore 
> <https://wiki.ivoa.net/twiki/bin/view/IVOA/ObsCore>standard itself if 
> you catch my drift.
>
> - Very much related to that, columns like instrument_and_diameter, 
> instrument_ant_number, or almost all instrument_ant_* for that matter, 
> are, for any array of radio receivers unhelpful. I have argued before. 
> In my opinion they'd fall under an instrument characterisation. I'm 
> also thinking of dipole or large-N-small-D arrays here, in the event 
> they'd want to publish some visibility data.
>
> Possibily a proper instrument characterisation mechanism can be 
> thought of, but in the end, only two things are important for 
> interoperability I think: what was the instrument signature at the 
> time of observation and has it been removed from the published data.
>
> My .02 arbitrary currency units, obviously.
>
> MarjoleinVerkouter 
> <https://wiki.ivoa.net/twiki/bin/edit/IVOA/MarjoleinVerkouter?topicparent=IVOA.ObsCoreExtensionForRadioData;nowysiwyg=0>2023-12-18
>
>
Humm, before ruling out all this, I just want to explain where it came 
from. This was not a fantasy of the editor or first authors.

To help a user to discover quality data we have to give a way to 
estimate this quality, by trying to characterize the original raw data.

Of the course the uv plane characterization is the best we can do, but 
if we cannot provide them whta can be done ? nothing ?

Our background was this rather old but very  comprehensive note by Anita 
Richards

https://wiki.ivoa.net/internal/IVOA/SiaInterface/Anita-InterferometryVO.pdf

The whole section 1.1 is to be read again.

But I would like to mention here these excerpts :

> Component telescope properties, such as location and diameter, can be 
> used to deduce other prop-
> erties if these are not provided explicitly. Should these be included 
> in this model or in Prove-
> nance/Observation (and/or a link to the array web page in the absence 
> of the latter models)

and

> Diagnostics of the uv plane coverage.
> – Most conventional radio archives provide links to plots (such as 
> Fig. 1) of visibility am-
> plitude as a function of uv distance This is in dimensionless units of 
> (projected baseline
> length)/(observing wavelength), or SI multiples, written as e.g. Mλ 
> (mega-lambda).
> – Table 1.1 provides a machine-readable quantification of Fig. 1.
> – The range of the maximum and minimum uv distances present in a data 
> set is the simplest
> fairly accurate quantifier. The example shown in Table 1.1 gives 
> 114.93–3553.52 kλ.
>
> – The range of intermediate spacings available as well as the limits 
> of uv coverage affect the data
> quality. There is no commonly-used universal quantifier for this 
> although the coverage could
> be described in more detail using the finer levels of 
> Characterization. Astronomers usually
> inspect plots such as Fig. 1 or the dirty beam (see Section 1.2 and 
> Fig. 2). The time axis also
> provides some information, see below.
> *– A crude estimate of coverage can be obtained from the number of 
> participating telescopes,
> the maximum and minimum baselines on the ground in m or km and the 
> duration of the
> observation*
(last item bolded by me)

So if  the data provider is not able to quantifify the uv plane quality 
some of these instrumental details seem to be useful

In addition, immediatly before we started the radio interest group in 
the VO there was an Asterics project / ESCAPE project initial work on that

which happened to be a first contribution.

A dedicated meeting on "radio astronomy data in the VO" was held in 
Strasbourg in february 2019.

Several radio astronomers gave talks about their needs and requirements 
for data discovery.

Loook at Katarina Lutz presentation here :

https://www.asterics2020.eu/dokuwiki/lib/exe/fetch.php?media=open:wp4:wp4techforum5:talk_klutz.pdf

or Yelena Stein's one

https://www.asterics2020.eu/dokuwiki/lib/exe/fetch.php?media=open:wp4:voradio_stein_.pdf

I copy paste you two interesting slides (one from each of these two 
talks) below

So my conclusion : I understand we still have to discuss the details and 
science cases. But do not exclude instrumental and configuration details

to early.

Cheers

François





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20240308/bc31af16/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unOpwkY0lS0R2RI5.png
Type: image/png
Size: 638625 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20240308/bc31af16/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bM7V9Rh9MdSuI9ma.png
Type: image/png
Size: 251892 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20240308/bc31af16/attachment-0003.png>