[Radioig] ObsCore extension last news

[Markus Demleitner]

Dear Radio IG,

On Wed, Nov 08, 2023 at 08:55:17PM +0100, BONNAREL FRANCOIS wrote:
>     There are now two new documents to review in order to progress towards
> the specification
>
> 1 ) https://wiki.ivoa.net/internal/IVOA/ObsCoreExtensionForRadioData/ObsCoreExtensionForRadioData-2023-11-07.pdf

You'll not be surprised that I still think sect. 4.2, f_min and
f_max, is a bad idea and you should rather require an ivo_specconv
function as discussed before; it'll also immediately placate folks
who want Hz, MHz, GHz, or THz instead of the kHz you went for.

More importantly, though, please don't do this:

[Doc:]
> The ObsCore extension for radio (including or not visibility data)
> described above SHOULD be added to the main ObsCore table.

This is painful for data centres that have only a few radio items and
millions of non-radio items (such as me).  In effect, you'd be
forcing me to do a massive denormalisation of my data.  And yes,
people shouldn't do SELECT *, but they do, and then they have all
these extra columns with NULLs in them for no benefit at all, in
particular because you acknowledge it'd be a joined view anyway.

On the other hand, *if* there were some overriding reason to have the
columns in the main obscore table, then don't make it SHOULD.  If
this is supposed to work at all, it must be a MUST -- software doing
radio obscore queries has to be able to rely on it if it's necessary
for some of your usecases.

But as I said: I don't believe it's necessary, and then we shouldn't
do it, neither as SHOULD or MUST (I take the liberty of citing my own
https://blog.g-vo.org/requirements-and-validators.html in support of
this argument).

[Doc:]
> In practice a table containing only the extension attributes MAY be
> added to the same schema.

That's where I believe the MUST needs to sit.  That way, your sample
queries will have a JOIN (my advice based on RegTAP experience: make
it a NATURAL JOIN and leave it to the implementors what the join
columns actually are).  Side benefit discovery rules are a lot
simpler.

You'd just be saying:

  Register the obscore extension as a VODataService CatalogService
  with a tableset only containing the ivoa.obsradio [or whatever;
  feel free to suggest a different name. I'd also be open to
  loosening naming schemes for ivoa.obscore, but I don't think the
  radio extension is the place to start that discussion] table.
  Assign a table utype of ivo://ivoa.net/std/obscore#radioext-1.0 to
  that table.  For later extensibility, discover radio-extended
  obscore tables using this utype (rather than the table name).  In
  RegTAP, you would find TAP services having radio extensions like
  this:

    SELECT access_url, table_name
    FROM rr.capability
      NATURAL JOIN rr.interface
      NATURAL JOIN rr.res_table
    WHERE
      standard_id='ivo://ivoa.net/std/tap'
      AND table_utype like 'ivo://ivoa.net/std/obscore#radioext-1.%'

I'd do a PR for that if you don't flame me too hard.

Also, if someone gives me radio data needing these extra columns, I'm
happy to do a reference implementation.

             -- Markus