Issue with discovering a TAP service in the RR

[Markus Demleitner]

Dear Laurent,

I've not really dug into this now (have to exit this train soon), but
very briefly:

On Fri, Oct 22, 2021 at 04:07:07PM +0200, Laurent Michel wrote:
>     SELECT  TOP 100    rr.capability.*, rr.interface.*
>     FROM rr.capability
>     JOIN rr.interface ON rr.interface.ivoid = rr.capability.ivoid
>     WHERE rr.capability.ivoid like 'ivo://cadc.nrc.ca/youcat'
>          AND rr.capability.standard_id = 'ivo://ivoa.net/std/tap'

While I cannot see anything wrong with this query in principle,
RegTAP is designed such that you can almost always do natural joins
and use unqualified column names, so you can write this as:

SELECT  TOP 100    access_url from
rr.capability
natural JOIN rr.interface
WHERE ivoid='ivo://cadc.nrc.ca/youcat'
  AND standard_id = 'ivo://ivoa.net/std/tap'

-- and that returns a single URL for me, as it should be.

For safety, you ought to add a 

  and intf_role='std'

but that's it.

>     I get 8 different URLs
> 
>     https://ws-cadc.canfar.net/youcat/capabilities
>     https://ws-cadc.canfar.net/youcat/availability
>     https://ws-cadc.canfar.net/youcat/logControl
>     https://ws-cadc.canfar.net/youcat/tables
>     https://ws-cadc.canfar.net/youcat/table-update
>     https://ws-cadc.canfar.net/youcat/load
>     https://ws-cadc.canfar.net/youcat/permissions
>     https://ws-cadc.canfar.net/youcat
> 
> 
> The problem:
> ============
>     I do  not see how can I identify the TAP service I can
>     connect (https://ws-cadc.canfar.net/youcat in fact) since all are
>     declared as ivo://ivoa.net/std/tap.
> 
>     Note that the problem goes out if I'm using NATUARL JOIN because it turns out that
>     only the last row is selected in that case
> 
> 
> Is that a registration issue, a RR flaw or a misunderstanding from our side?

If such a thing comes back, it would be a problem with the data
provieder's registry record.

Have to leave -- feel free to ask back if I'm missing something
major.

       -- Markus