Referencing tables from capabilities

[Gilles Landais]

Hello Markus ,

Thank for the proposal,
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.

I agree with the proposal.
A relation 0..1 (one capability for 0 or one table) covers our usage today.
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).
It would be appreciated for clients (I guess) to use the same method.


Regards

Gilles


On 8/21/26 09:52, Markus Demleitner via registry wrote:
> 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<https://github.com/ivoa-std/VODataService/pull/27>
> 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">http://dc.g-vo.org/bla</accessURL>
>        <queryType>GET</queryType>
>        <resultType>application/x-votable+xml</resultType>
>        <param ...>
>        <param ...>
>      </interface>
>      <forTable>gaia.dr3lite</forTable>
>    </capability>
>
> [based on
> http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/gaia/q3/cone]
>
> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20260824/d9e84819/attachment.htm>