TAP usage in practice - we have a small problem.
msdemlei at ari.uni-heidelberg.de
Fri May 19 04:57:29 CEST 2017
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:
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
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) has now become
VODataService plea for takeup [although I have to correct myself:
relationships are of course part of VOResource, not VODataServer]
More information about the registry