UCDs and DataLink

[Dubois-Felsmann, Gregory P.]

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.

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