<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><br>
Hi,<br>
<br>
The problem with capability multi definition is the various people
interpretations of what is a capability.<br>
<br>
We already find in the VO registry multi-capabilities for
accessing :<br>
<ol>
<li>disjoint partitions of a collection (ex: North and South
table of DENIS catalog)</li>
<li>various tables of a collection (ex: Gaia main, Gaia TGAS)</li>
<li>various versions of a collection (ex: DR1, DR2, DRnn of
UKIDSS)</li>
<li>various protocols for a collection (ex: SIA, TAP, SIAv2,
HiPS, etc)</li>
<li>various web implementations of a collection (mirror
management)</li>
<li>and probably more<br>
</li>
</ol>
<p>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). <br>
</p>
<p> 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).<br>
</p>
<p>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....)<br>
</p>
<p>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.
</p>
<p>Cheers<br>
Pierre<br>
</p>
<br>
Le 13/04/2018 à 09:40, Markus Demleitner a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20180413074019.wtd36n4u2dtlkxzo@victor">
<pre wrap="">Hi,
On Fri, Apr 13, 2018 at 08:09:55AM +0200, Marco Molinaro wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
And here is registry field.
>From my poor knowledge I would say "yes", but I leave word to registry
experts.
</pre>
</blockquote>
<pre wrap="">
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
(<a class="moz-txt-link-freetext" href="http://ivoa.net/documents/Notes/discovercollections/20161111/">http://ivoa.net/documents/Notes/discovercollections/20161111/</a>).
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
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>