[Radioig] Obscore extension for radio: review, implementation point (3)

[BONNAREL FRANCOIS]

Hi Markus, Marjolein,
Thanks you for reading the document carefully and providing feedback.

I address here the f_min/f_max point where I will explain why we 
introduced that and why I persist to think it is to be kept.

Le 18/12/2023 à 09:07, Marjolein Verkouter a écrit :
>
> - I would advocate (very) strongly to not record the same information (em_min/max, f_min/max) in the same table but make it easy to query on energy, wavelength, or frequency by adding convenience functions, such as Markus proposes at some point. For the raw table information let's stick to one (1) physics representation.
>

Le 11/12/2023 à 13:46, Markus Demleitner a écrit :
>
> (1) The longer I think about them, the less I like f_min and f_max.  If
> you look at use case 1.3: "range inside the 1 to 1.5 Ghz band" -- and
> then people have to write f_min > 1000 AND f_max < 1500 and thus do
> some conversion anyway, and to the relatively random unit MHz on top.
> Please let's reconsider this; I have sympathies for not wanting to
> write the λ-ν conversions manually, but if
>
> 	1 = ivo_interval_overlaps(
> 		em_min, em_max,
> 		ivo_specconv(1.5, "GHz", "m"),
> 		ivo_specconv(1, "GHz", "m"))
>
> doesn't work for you, let's think again and figure out something that's
> less verbose.  But let's not define something parallel to em_min and
> em_max with an even more random unit than m.

and t Mark Kettenis Markus answered


>>> as using "Mhz" but f_resolution as using "kHz").  We do need to retain
>>> f_resolution though as em_res_power simply varies too much for
>>> low-frequency observations that span a large fractional bandwidth.
>>> Radio observations typically have a fixed frequency reolution (and
>>> therefore varying resolving power) across the band.
>> For the record, I totally see the f_resolution agenda, but I'd
>> mildly advocate Hz as its unit.  That's for intellectual economy
>> ("um... was it kilohertz?  ...megahertz?  ...gigahertz?") and
>> because I feel writing f_resolution<30 isn't so much better than
>> writing f_resolution<30e3 as to justify memorising SI prefixes.
>

Yes I think it's reasonable to use the same unit, Hz for all the 
frequency fields. We will change that in the draft.

  That's much simpler than to find the right multiple for any quantity 
and sub domain. You are right!


As for the frequency characterization, I would advocate :

Why are we building an ObsCore extension for radio data  ?

We are indeed speaking of data discovery.

"core ObsCore" metadata help to discover any kind of datasets in any 
spectral domain. But in the radio domain some specificities are not well 
enough taken into account by the standard.

And this is specifically the case for raw data (visibilities in the 
radio case)

The consequence is that the result of a query is only roughly matching 
some of the discovery tasks.

The basic idea with the ObsCore extensions is the same than the one we 
enhanced by creating some Optional fields in the original ObsCore. Not 
forcing anything but ALLOWING to add details in order to better tackle 
some specific needs.

When the CSP identified the rather low uptake of VO service in the radio 
domain and defined the goal to fix that as an IVOA priority, and when in 
parallel the Euro-VO Asterics project (+ESCAPE) held several sessions 
around this, the first thing we heard from many/many radio astronomers 
and potential users was :

"Hahh, gosh .... Wavelengths !!!"

After explaining these colleagues why we definitely  needed a common 
language for everybody and why wl is the minimal lingua franca, we also 
considered to provide them with a couple of additional fields useful for 
them.

In practice I imagine many radio archives start by storing their 
metadata in frequencies and transform them into wavelengths using 
functions, views or whatever to be consistent with ObsCore.

So for sure conversion udf probably exist anyway. But this is 
implementation.

But If we provide an extension, then this extension should be easy to 
use for queries and for metadata visualisation for the users. And also 
for client developers.

Nobody is forced to use a radio extension. But if people are in the 
spirit of using it then this has to be easy and readable for them.

Last thing : if we have a parameter based interface to ObsCore (and 
extensions) in a near future (see :https://github.com/ivoa-std/DAP), 
frequency characterization will be provided with an optional parameter 
and with standard column names anyway.


Cheers

François





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/radioig/attachments/20231222/1331d480/attachment.htm>