Can an SIA service support both V1 and V2?

[Pierre Fernique]

Hi,

The problem with capability multi definition is the various people 
interpretations of what is a capability.

We already find in the VO registry multi-capabilities for accessing :

 1. disjoint partitions of a collection (ex: North and South table of
    DENIS catalog)
 2. various tables of a collection (ex: Gaia main, Gaia TGAS)
 3. various versions of a collection (ex: DR1, DR2, DRnn of UKIDSS)
 4. various protocols for a collection (ex: SIA, TAP, SIAv2, HiPS, etc)
 5. various web implementations of a collection (mirror management)
 6. and probably more

Another problem already described with capability is the lack of 
associated meta data description which is unfortunately only provided at 
the top collection level (ex: there is no way to describe coverage at 
capability level,  etc).

Notice also that we have already some services which provide multi 
top-level records for the same collection, but with different protocol 
(ex: NED SIA / NES SIAv2).

For the client point of view, it means some delicate assumptions and a 
few "hard coded" hacks. Concretely, Aladin V10 tries to take into 
account all existing capability interpretations, but I have to say that 
the result is not as good as I would like. And we have regularly 
questions of users concerning the related issues (why I do not found 
CADC image service in SIAv2 tree branch ? why I query simultaneously 
various UKIDSS versions, I only need one. Why I have two SIA methods for 
the same collection and do I get the same results....)

I do not say that multi capabilities is not adapted for multi-protocol 
definitions, but it would be a good idea to have a action to clean and 
tag without ambiguity the various usages.

Cheers
Pierre


Le 13/04/2018 à 09:40, Markus Demleitner a écrit :
> Hi,
>
> On Fri, Apr 13, 2018 at 08:09:55AM +0200, Marco Molinaro wrote:
>>> One thing that I am unable to wrap my mind around is how this gets put in
>>> the registry.  Do we just
>>> register two capabilities using the same base URL?
>>
>> And here is registry field.
>>  From my poor knowledge I would say "yes", but I leave word to registry
>> experts.
> It's a clear yes.  You  want different capabilities with different
> standard ids so clients will locate your services, but there's
> nothing wrong with having the same access URL in interfaces of two
> different capabilities.
>
> Tow brief considerations on this:
>
> (1) I've been telling people to use
>
>    select email
>    from rr.res_role
>    natural join rr.interface
>    where access_url='<whatever>' and base_role='contact'
>
> to figure out who to complain to if something is wrong with a service
> at <whatever> -- but as long as contact is the same for the different
> interfaces, that's still going to work, perhaps dumping several rows.
> But that's already going to be the case with auxiliary capabilities.
>
>
> (2) The pattern proposed by Tom might even help with a thing that's
> been on my mind in that field for a while -- suppose clients start
> doing all-VO searches on SIAv1 and SIAv2 at the same time -- as SIAv2
> gets taken up, more and more data sets would be shown twice (or even
> three times, when the client also does obscore).
>
> SIAv1 doesn't have publisher DIDs (and quite a few services will
> botch these in SIAv2, at least if we go by the experiences with SSAP)
> -- reliably weeding out dupes (at least on the level multi-protocol
> access) therefore is going to be at least tricky.  *If* identical
> access URLs were to become a common pattern, clients could at least
> mitigate the situation by removing dupes from the access URLs
> discovered.
>
>
> Incidentally, at the GAVO data center (and in DaCHS in general),
> we're going the other way -- there are many SIAv1 services but only
> one SIAv2, which, obscore-style, serves all images available in the
> data center.  The individual data collections are registered
> using auxiliary capabilities
> (http://ivoa.net/documents/Notes/discovercollections/20161111/).
>
> Client support for that pattern perhaps isn't all brilliant yet, but
> at least it's going to help a lot to keep all-VO queries feasible.
>
>           -- Markus
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20180413/a75d4991/attachment.html>