RegTAP service discovery queries

[Markus Demleitner]

Hi Mark,

On Thu, Jun 13, 2019 at 10:32:00AM +0000, Mark Taylor wrote:
> some of the recommended queries (Section 10) in PR-RegTAP-1.1
> have changed since REC-RegTAP-1.0, in particular the the standard
> service search constraints
> 
>    "intf_role='std'" instead of "intf_type='vs:paramhttp'"
> 
> and changes to standard_id matching, e.g.
> 
>    "standard_id LIKE 'ivo://ivoa.net/std/sia%'" instead of
>    "standard_id='ivo://ivoa.net/std/sia'"
> 
> I want to know whether I should make corresponding changes to the
> RegTAP queries made by TOPCAT; such queries are used to discover
> Cone, SIA, SSA, TAP (sometimes) and RegTAP services.

For intf_role='std', just do it.  intf_type='vs:paramhttp' was a
workaround for a problem that's fixed now, and it unnecessarily
constrains future developments.

As to loosening up the standard_ids, that depends:

> If I makes such changes is it going to improve my query results?

If you're doing what DDC (http://ivoa.net/documents/discovercollections/)
calls data discovery ("are there services having data like X from
instruments like Y?"), it might.  [In truth, outside of TAP, almost 
nobody does auxiliary resources at this time, so your results
wouldn't change a lot]

If you're doing what DDC calls service enumeration ("Give me all SIAP
services"), your results would get worse, because services pointed to
by auxiliary capabilities will be present in your service select
multiple times and would, in an all-VO query for instance, be hit
multiple times, too.

For TOPCAT, it's not trivial to say what it's doing, because it kind
of does both through one interface.  I'm almost tempted to say "Do a
service enumeration for your initial display listings, and a data
discovery if people have entered terms".  But then, of course, people
running a search will see things that the ones just browsing the
service lists will not find, which may be undesirable.

Very frankly: As long as I'm the only data center that actually has
auxiliary capabilities for SIAP and SSAP, I'd not touch the code
TOPCAT has behind the respective windows.  You'll only see the
"collective" services, and if anyone were to look for, say, Maidanak
observatory, they wouldn't find anything although they could with
auxiliary capabilities, but this seems acceptable at least until
other data providers feel the need for common SIA interfaces for
multiple data collections.

As for TAP, migrating TOPCAT from GloTS to RegTAP is a more involved
endeavour, and we should have some extra discussion about it.


> Might it break anything?  Should I only use these altered forms

intf_role=std: Not in the Registry as of a few weeks back.  Meaning:
all vs:ParamHTTP interfaces TOPCAT might be interested in had a
role="std", too.  

Allowing auxiliary capabilities: Well, for loose interpretations of
"break" (e.g., hitting a service for no good reason is allowed) the
new patterns of course shouldn't break anything.  If you went
to TAP, you'd suddenly have 2e4 TAP services (because most of VizieR
records have an auxiliary capability), and that quite likely would be
breaking at least the TAP service browser.

> when talking to RegTAP 1.1 services?  Are there any RegTAP services

These two changes are not version-dependent and thus can be applied
regardless of the version on the other side.

> out there which are not (or don't behave in relevant respects like)
> RegTAP 1.1?  Should I wait until RegTAP 1.1 is in REC?  Are there
> any other things I should worry about here?

I've not yet heard of the plans at ESAC.  STSci, I think, is on 1.1
already.

About waiting: Well, migrate at your leisure.  It'd obviously be
ideal if you could see if you could implement enough of the client
part to see if any of the changes break anything in TOPCAT; I don't
think there's any hurry to rush out code to the users.  Perhaps if
you wait another couple of months, all RegTAP systems will be on 1.1
and you can just drop support for 1.0?

As to other things you should worry about: Well, apart from me
striving to replace GloTS with tableset through RegTAP: None that I'm
aware of now.

         -- Markus