TAP usage in practice - we have a small problem.

[Markus Demleitner]

Dear VO,

First off: I'd suggest to route further discussion of this topic to
the registry mailing list to avoid creating too much noise.

On the topic:

On Thu, May 18, 2017 at 05:51:43AM +0200, Pierre Fernique wrote:
> I would suggest to *add in the VO registry record of the TAP capability of
> this table the name of the internal DB table associated to*.
> 
> Obviously, the one to one table correspondance is not always the case. For
> instance, Simbad is not described by one unique DB table. But for big TAP DB
> - such as VizieR, IRSA, HEASARC.... it is the case. And the problem occurs
> especially for these kinds of servers.
> 
> Comments ? Remarks ? Others ideas to solve the problem ?

Of course, the Registry's founding fathers had thought of this
paritcular problem and gave us the vs:tableset type that allows the
declaration of table metadata per record.

This isn't quite enough to solve the table discovery use case when
there are multiple data collections in a TAP service, though.  The
second ingredient are the "auxiliary capabilities" (currently in RFC,
which is one more reason to try them:
http://wiki.ivoa.net/twiki/bin/view/IVOA/Discovercoll11RFC).

Admittedly, Registry outsiders will still have a hard time figuring
out the right way to declare their TAP services.  Therefore, I've
written up a step-by-step guide for authors of TAP-related registry
records at

http://wiki.ivoa.net/twiki/bin/view/IVOA/HowToEnableTableDiscovery.

It'd be great if the major TAP service operators could have a look
and ideally implement these steps; if my attempt at explaining the
why and how plainly, or if you disagree with the approach of the
auxiliary capabilities as such: Please speak up as soon as possible
-- Pierre's mail shows that the whole issue of discovering dependent
resources (something that we've been chewing on within the Registry
WG off and on since the Naples interop in 2011[1]) has now become
really urgent.

Thanks,

           Markus

[1] Proof:
http://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2011Registry, the
VODataService plea for takeup [although I have to correct myself:
relationships are of course part of VOResource, not VODataServer]