UCDs and DataLink

[BONNAREL FRANCOIS]

Dear Gregory, dear all,
Le 09/08/2022 à 12:13, Dubois-Felsmann, Gregory P. a écrit :
> On https://github.com/ivoa-std/DataLink/issues/89, I raised, on behalf 
> of my colleague Russ Allbery who had noticed the point, an issue about 
> an inconsistency between the prescribed UCD of a column in the 
> _output_ of "{links}" resources and its use as an _input_ to a SODA 
> service.
>
> This came up when we were implementing both of these services in the 
> Rubin Science Platform.
>
> Comments on the specific proposal I made in the GitHub issue should 
> stay there, but in his response, Markus reacted to a more general 
> point I made in the issue, and suggested that there might be something 
> for us to discuss on a mailing list, regarding the larger issue of 
> whether we care about such compatibility issues at all, and what the 
> purpose of UCDs is.
>
> As I said on the GitHub issue, from a client software perspective, it 
> seems plausible that a client should take a service descriptor's word 
> as law, and not try to second-guess whether a column named by a 
> service descriptor is UCD-compatible with the service parameter in 
> which it is intended to be used. It might only be for validators to 
> comment on such issues.
>
> But Markus made a stronger point, which I think I can go ahead and 
> quote, since the issue is public:
>> I'd argue against making any requirements on UCDs [in these sorts of 
>> contexts].
>> UCDs are mainly intended for ad-hoc or discovery use, like:
>>
>> * a client sees an arbitrary VOTable and wants to get an idea what
>> kind of physics is represented in order to suggest plots for it,
>> perhaps match it with columns in other tables or similar.
>>
>> * a client is looking for tables having a particular sort of data in
>> the registry.
> I'd like to push back a bit on how narrow that field of applicability is.
>
> In particular, in the context of service descriptors, we are finding, 
> as we actually implement the DataLink-intensive design of the Rubin 
> Science Platform (RSP), that client software often needs some hints as 
> to how to present, in a UI, the "optional" parameters to a service 
> named in a service descriptor. If a service descriptor represents a 
> service for which there is an IVOA standard, of course, the client 
> software UI can be written against the whole of that standard. But if 
> (as is _very_ frequently the case for us) the service descriptor 
> points to a custom data service, the UCDs can be useful in providing 
> rendering hints without our having to hard-code the client software 
> against the specifics of the custom data services.

I would say it depends what you want the UI to take into account . If 
the quantity represented by the parameter is the only thing to be taken 
into account then the ucd should be perfectly fine. If something like a 
role or a format is of interest, we can also use utype and xtype.

In a footnote of the SODA spec there is something about relation of the 
SODA input parameters and ObsCore utypes. ObsCore utypes define the 
characterization of the datasets ( in the sense of the char datamodel). 
IN the context of SODA , some input Parameters force the 
characterization of the cutout dataset.

I imagine that for services dealing with spectra, some utypes of the 
currently revised version of SDM could help.

As a matter of conclusion I think your concern can be solved by 
appropriate definition of a combination of ucd,utype, xtype and unit of 
the input parameters to describe.

Best regards

François

PS : To be clear : this usage of utypes I am talking about is not 
related to the issue of mapping datamodels to VOTable for which MIVOT is 
the right solution. IN practice in the IVOA utypes are used to tag roles 
and a good way to do that is to point them to datamodel leaves when 
available. this is different from a full mapping as we know.

> We _could_ do the latter, but it creates tighter coupling and 
> fragility in our deployments, and I would also like non-RSP client 
> software (e.g., TOPCAT) to have a reasonable chance at providing good 
> UIs for our service descriptors.
>
> Looking forward to the conversation...
>
> Gregory Dubois-Felsmann