InputParam to make interface-table relationship

[gilleslandais]

I propose to add a section/paragraph in the VODataService document.

Motivation : it won't be used if not documented.

This capability is interesting for VizieR, but also for any other data centers that provide in a registry record (CatalogResource or CatalogService) a collection of tables that can be queried via dedicated services.
(eg: a service described in a capability is only used for a subset of tables).
This is possible with simple Cone Search (but also in the future with HaTS, HiPS or SCS2).

In the current Document, the issue seems to be reported in section 3.3.3, item (3) as a "possible" update.
But vs:inputParam is already a possible response!

(naive) proposal (please update with a better language :) or in another place of the document)

In section 3.1.4:
"VODataService allows relation n-m between tables and vr:capabilites.
The relation can be formalized within vr:interface (versus vs:paramHTTP) , see section (vs:inputParam to link tables and capabilities)'

Add a new paragraph or a section in or after section 3.5.2 "vs:inputParam to link tables and capabilities"

"vs:paramHTTP allows to link capability with one or multiple tables described in the same vs:CatalogService.
To do, it needs to add a parameter ("param" element) into the "interface" element. The parameter name is "TABLE" (this parameter is used in the accessURL , SCS2 for instance) and its values are enumerated using vs:Stats with "option" element.

Example : see github"

[msdemlei]

Hm. Count me as unconvinced. Although...

On Fri, Jul 03, 2026 at 07:11:49AM -0700, gilleslandais wrote: This is possible with simple Cone Search (but also in the future with HaTS, HiPS or SCS2).

Well, that there are other protocols that may have a need for saying "this service is exposing this particular table from this resource's tableset" is an argument to mention this in VODataService. But is this a case for HiPS? And for HATS... I've not actually played with it but for all I can see it doesn't have something like the TABLE parameter in SCS2. Hence, it would probably have to have something like a dedicated forTable child in its capability if that's what the HATS people need (and I'd not be surprised if they did). Soooo, I'd see the param[name=TABLE]/stats as a thing fairly specific to SCS2, and thus I'd prefer if we discussed it there.

In section 3.1.4: "VODataService allows relation n-m between tables and vr:capabilites.

Having a more general discussion about the relationship between tables and capabilities in VODataService is something I'd find useful, though. What about text like this (feel free to adapt and turn it into a PR if this scratches your itch): More complex resources may contain a tableset with multiple tables and several capabilities which may then operate only on a subset of them. As an example, consider a resource with three tables, one containing information on spectral lines employed by that resource's creators, the other two two sets of objects with different metadata schemes. This could have an auxiliary TAP capability serving all tables, a SLAP service for the spectral lines, one cone search service each for the two object tables, and perhaps a datalink service linking object rows to the progenitor spectra, which would work for both object tables. VODataService does not have generic mechanism for capturing the n:m relationship between tables and capabilities. This is because id/idref-based methods are very hard when resource records are frequently combined into joint documents like OAI-PMH responses. Also, exploiting metadata of this type in discovery usually leads to ugly query patterns. Links between capabilities and tablesets can still be maintained using extra metadata within extended capability types. For instance, the name of a table below a service could be in a child element of the capability. In SCS2, the link is expected to be implemented through metadata of the \xmlel{vs:ParamHTTP} interface, where the table name(s) suitable for cone queries are given as options in the TABLE parameter's \xmlel{stats} child. I'm not 100% happy with VODataService saying something about SCS2, the REC of which is quite a bit in the future, but I think I could live with that. What do you think?

[gilleslandais]

Thank for the explanations, I may have gotten excited a little quickly with HTTPParam -
I understand better HTTPParam, but also its limitation.

HTTPParam works with the protocol and has not to be used as a 'general' table-capability linking.
(I 'm not sure that there are other protocol than SCS2 having a parameter to specify the resource - even TAP and certainly not "HIPS server" which is very far from DALI)

(note that HATS and HiPS catalogues are dedicated for table)

I expected to use the "stats" options for SCS (version1) and also for HATS (my plan for HATS was to add HATS capabilities into existing VizieR vs:catalogService record). I'm a litle disapointed

"VODataService allows relation n-m between tables and vr:capabilites.
Having a more general discussion about the relationship between
tables and capabilities in VODataService is something I'd find
useful, though.

clearly yes - but the current proposal is limited - I would be very happy to add a discussion (may be not in this release) to find a general way.

Adding parameter in the capabilty is intersting to factorize capabilities.
For SCS2 (but it's not a standard yey), it could be used as an implicit method to link table definition.

I agree with your text - except the 2d paragrpah

More complex resources may contain a tableset with multiple tables
and several capabilities which may then operate only on a subset of
them. As an example, consider a resource with three tables, one
containing information on spectral lines employed by that
resource's creators, the other two two sets of objects with
different metadata schemes. This could have an auxiliary TAP
capability serving all tables, a SLAP service for the spectral
lines, one cone search service each for the two object tables, and
perhaps a datalink service linking object rows to the progenitor
spectra, which would work for both object tables.

ok (even if I don't understand the datalink)

VODataService does not have generic mechanism for capturing the n:m
relationship between tables and capabilities. This is because
id/idref-based methods are very hard when resource records are
frequently combined into joint documents like OAI-PMH responses.
Also, exploiting metadata of this type in discovery usually leads
to ugly query patterns.

I'd prefer to remove this paragraph which possibliy close future update.

Links between capabilities and tablesets can still be maintained
using extra metadata within extended capability types. For
instance, the name of a table below a service could be in a child
element of the capability. In SCS2, the link is expected to be
implemented through metadata of the \xmlel{vs:ParamHTTP} interface,
where the table name(s) suitable for cone queries are given as
options in the TABLE parameter's \xmlel{stats} child.

ok,
I try an other explanation:

\xmlel{vs:ParamHTTP} interface allow to factorize in a same capability the access to several datasets.
That's possible when the resource can be filled in accessURL parameter using value enumerated in \xmlel{stats} childs. For protocol such as SCS2; it could make an implicit linking with vs:table when the parameter is "TABLE".

.. .but id it better ? ...

[msdemlei]

On Wed, Jul 08, 2026 at 05:47:05AM -0700, gilleslandais wrote: > VODataService does not have generic mechanism for capturing the n:m > relationship between tables and capabilities. This is because > id/idref-based methods are very hard when resource records are > frequently combined into joint documents like OAI-PMH responses. > Also, exploiting metadata of this type in discovery usually leads > to ugly query patterns. I'd prefer to remove this paragraph which possibliy close future update.

:-) Well, it explains why a general mechanism is at least *hard* and why id/idref is close to impossible: We would have to devise some way to either * do something beyond id/idref that's different from just doing per-protocol techniques to include table names below capability (which is what I propose here), or * force people to choose globally unique ids (and just prepending the authority is at least going to be exceedingly brittle), or * change our OAI-PMH implementations such that they adjust id/idref pairs during serialisation (which might work but is a nightmare). None of this seems remotely attractive, and thus I think *if* we say something at all about why there's no general capability/table linking, this paragraph is the central one.

\xmlel{vs:ParamHTTP} interface allow to factorize in a same capability the access to several datasets. That's possible when the resource can be filled in accessURL parameter using value enumerated in \xmlel{stats} childs. For protocol such as SCS2; it could make an implicit linking with vs:table when the parameter is "TABLE". .. .but id it better ? ...

I think there's a typo here? If the question was "but id is better?", my answer would be: A general technique would be nice, but id/idref just is too hard to pull off after my considerations above. I think that if we establish a forTable element in extensions for HIPS and HATS and while trying those out find they work nicely, that could be turned into a pattern. But I wouldn't like to propose that while it's not even been spelled out properly.

[gilleslandais]

(it was a typo, I mean "but is it better ?" (refer to the paragraph text))

• do something beyond id/idref that's different from just doing
  per-protocol techniques to include table names below capability
  (which is what I propose here), or

it was my first choice - I don't think it is ugly?
(In College-park, serve is an element of vr:capability)

<capability xsi:type="cs:ConeSearch"  standardID="ivo://ivoa.net/std/ConeSearch">
     <serves>
         <reftable name='table1' />
         <reftable name='table2' />
     </serves>
</capability>
...
<tableset>
     <schema>
        <table>
            <name>table1</name>
...

[msdemlei]

On Wed, Jul 08, 2026 at 10:01:58AM -0700, gilleslandais wrote: gilleslandais left a comment (ivoa-std/VODataService#22) <capability xsi:type="cs:ConeSearch" standardID="ivo://ivoa.net/std/ConeSearch"> <serves> <reftable name='table1' /> <reftable name='table2' />

I would probably just say <for-table>table1</for-table> in a direct child for simplicity, but that's a detail. However, I don't think we need that for SCS2 (where TABLE stats do what we need in a way that doesn't require clients to do anything they shouldn't be doing anyway: retrieve the capabilities and figure out what sorts of parameters they can pass). For other capability types, a mechanism like for-table might be useful, but as I said I'd *much* rather wait until we write these extensions and have actual use cases that let us evaluate whether that's the right way to go. I'd really like to ensure we are actually solve a data discovery problem with a construct like that. By the way, the reason this is simple against what I said above is that it's not id/idref and the references are resolved only within the current resource's tableset. Such a construct doesn't need complicated manipulations when combining resource records in OAI responses.

[gilleslandais]

in any case, this capability extension has not to be in VODataService 1.3.
(to see in another VOResource version)

So, that's ok for inputParam, that's ok for the added text (except the 2d paragraph for me).
.. and understanding now better inputParam, it's also ok for the "stats" semantic :)