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

[Marjolein Verkouter]

Hi all,

Chiming in a bit late, I'd like to say a few things:

First of all, *many* thanks to Markus for carefully reading and following suggestions on the Radio extension, much appreciated!

Briefly:

- 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.

- Given that 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 of ObsCore but could live outside the 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.
Cheers,
M

-----
Marjolein Verkouter (she/her)
Head Technical Operations and R&D

JIVE — Joint Institute for VLBI ERIC —
https://www.jive.eu/
Oude Hoogeveensedijk 4, 7991PD, Dwingeloo, The Netherlands
Phone: +31521596516
Mobile: +31625055174
Fax: +31521597332

My working schedule likely differs from yours. Do not feel compelled to read or reply to my email(s) outside office hours.


> On 14 Dec 2023, at 10:58, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
>
> Dear Mireille,
>
> On Wed, Dec 13, 2023 at 03:28:39PM +0100, Mireille LOUYS wrote:
>> Do you mean you do not want to use utypes for the extension table :
>> 'ivoa.obs_radio' or also for 'ivoa.obscore'.
>
> I don't want to make this a major point, but I cannot fail to notice
> that utypes do not have any operational role in either obscore nor
> obs_radio -- there is nothing any software does with them, or any
> functionality that wouldn't be available if they weren't there. To
> me, that mildly poses the question of why we bother with them.
>
>> The quantities that are stored in the columns need to belong to some more
>> general schema carrying the context.
>
> We could discuss that in itself, but more pragmatically: do the
> utypes really help to link to that context?  I mean, not even I know
> *what* to look up *where* when I see the string
>
>  Provenance.Observation.sky_scan_mode
>
> -- and certainly no machine could do that; so, why not just state
> whatever context link there may be in the spec rather than bothering
> implementations and validators with it?
>
> But my point was still a lot more trivial: I'm much rather drop that
> string altogether than quarrel whether that ought to be SkyScanMode,
> which I think would make it a bit more consistent with the other
> obscore utypes.
>
> But feel free to drop the whole thread:  While in general I much
> prefer it when what we *require* is something we actually *need* in a
> standard so it works (long version of that thought:
> https://blog.g-vo.org/requirements-and-validators.html) -- and that
> is certainly not true for the column utypes here --, I feel this
> isn't a good place to re-think age-old VO practices, either.
>
>          -- Markus