More UCD woes

[Patrick Dowler]

I am sure the intent was always to move with later versions of ObsCore, so
I think it is just that at the time we put the ref to the only existing
version. The language you quoted is certainly my attempt to just refer and
not repeat the ObsCore spec. How should we be making references so they are
forwards compatible e.g [ObsCore-1.0, ObsCore-2.0)? If we could have done
that, is this an erratum to fix it?

Practically, I can think of an way to support both versions (ObsCore is a
view already) by having an ObsCore10 view with associated metadata in
tap_schema and then having SIA2 query that view instead of ivoa.ObsCore,
but it's ugh and I think users would want/expect SIA and TAP queries of
ivoa.ObsCore to be consistent... so I'd rather allow it than do this.
--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Wed, 4 May 2022 at 07:44, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Dear DAL WG,
>
> I'm sure you've all been waiting for my next nitpicking of UCD use in
> DAL.  Wait no longer.  Except: this time, the cut is a bit deeper.
>
> SIAP 2 in section 3.1 ("Successful Query") says:
>
>   The response from a successful call to the {query} resource is a
>   table consistent with  ObsTAP responses as described in [7].
>   The ObsCore data model specifies all the (VOTable) field names,
>   utypes, UCDs, and units to use in the response, as well as which
>   fields must have values and which are allowed to be empty (null).
>   The {query} response must contain the required ObsCore fields and
>   may contain additional fields (from [7] or custom fields from the
>   service provider). Examples
>
> [7] is a reference to Obscore 1.0, version-sharp.
>
> Which is where the trouble starts.  Because, between Obscore 1.0 and
> Obscore 1.1, the UCD of the s_region column was changed from
> phys.area;obs to pos.outline;obs.field.
>
> Ever since I've moved by Obscore schema to 1.1, my SIAP 2 response
> has thus be invalid (brown bag for having ignored that for so long;
> cheers to Renaud for making it straightforward to have a simple
> command for "how do my services do"?).
>
> I *could* rather easily repair that by fiddling in the old UCD if
> DaCHS realises it is talking SIAPv2, but: Is this what we want?
> Shouldn't SIAPv2 just say "any response compliant to Obscore version
> 1 is fine"?  And if not, why?  Would we then issue a new version of
> SIAPv2 whenever there's a new version of Obscore?
>
>         -- Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20220504/0ae9e3fd/attachment.html>