<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello Markus ,</p>
<p>Thank for the proposal,<br>
This is the situation in CDS. The resources in the registry
consist of catalogues, each of which may contain descriptions of
several tables and several capabilities with no method to link
them together yet.<br>
<br>
I agree with the proposal.<br>
A relation 0..1 (one capability for 0 or one table) covers our
usage today.<br>
But, in SCS2, the same capability could serve several tables in
the same catalogues (eg: Gaia or Corot catalogue contains both
several tables with positions accessible via SCS may be HATS in
the future). <br>
It would be appreciated for clients (I guess) to use the same
method.</p>
<p><br>
</p>
<p>Regards</p>
<p>Gilles</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 8/21/26 09:52, Markus Demleitner via
registry wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4vshreeetjpmeqc3jyy2uh5u3szchem4sduxsh6ffl3jszm2p2@3cqhx4v5amc4">
<pre wrap="" class="moz-quote-pre">Dear Registry,
On the way to the RFC for VODataService 1.3, we have thought quite a
bit about somehow linking capabilities with tables within a tableset.
Use cases for that include:
* Cone searches: A resource can have multiple tables suitable for SCS
services, and then there can be multiple SCS services to access
them. There currently is no machine-readable way to say which
capability is for which table.
* HATS/HiPS-tables: similarly, there are cases when several tables
can offer access via HATS or HiPS. Again, there is currently no
way to clearly say which capability matches which service.
There was PR #27 <a class="moz-txt-link-rfc2396E" href="https://github.com/ivoa-std/VODataService/pull/27"><https://github.com/ivoa-std/VODataService/pull/27></a>
that explained why this is non-trivial, but in the end this is a
pattern that appears fairly common and should probably be addressed
in a uniform way, not relying on the relatively haphazard method
currently envisaged for SCS2 (where you learn about the table names
by examining metadata from the TABLE parameter; this clearly is
SCS2-specific).
The relatively simple fix is to define in VODataService (which also
defines the tableset itself, which makes it the obvious place for the
definition) an extension of vr:Capability that just adds a forTable
element. It could perhaps be vs:CapabilityForTable, and then you'd
write something like:
<capability standardID="ivo://ivoa.net/std/scs2#query-2.0"
xsi:type="cs:CapabilityForTable">
<interface xsi:type="vs:ParamHTTP">
<accessURL use="base"><a class="moz-txt-link-freetext" href="http://dc.g-vo.org/bla">http://dc.g-vo.org/bla</a></accessURL>
<queryType>GET</queryType>
<resultType>application/x-votable+xml</resultType>
<param ...>
<param ...>
</interface>
<forTable>gaia.dr3lite</forTable>
</capability>
[based on
<a class="moz-txt-link-freetext" href="http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/gaia/q3/cone">http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/gaia/q3/cone</a>]
In SCS2, we'd still want the param[TABLE] stats to make it simple for
the clients, but on the registry side this is far more explicit, and
for HATS/HiPS and possibly VOEvent there's no param[TABLE] anyway, so
this isn't a option.
I am pretty sure that we want forTable 0..1 (or perhaps even
mandatory?) rather than 0..n; *if* we have standards that work on
multiple tables from a tableset, I'd submit they want custom
extensions.
I don't think this is terribly useful for discovery, and thus for now
I'd say this would end up in res_details in RegTAP. The intended use
would typcially be that clients pull capabilities and tableset from
the services directly once they know they'd like to use a table and
they want to figure out which service to use.
So, what does everyone think? Is there something wrong with this
reasoning? Should we get this into 1.3 or rather prototype it for a
bit in the 1.4 cycle?
Thanks,
Markus
</pre>
</blockquote>
</body>
</html>