HATS and HiPS in registry

[gilleslandais]

HATS/HiPS need (or not) a registry extension (like SCS for instance)?

see also @delucchi-cmu presentation (https://wiki.ivoa.net/internal/IVOA/InterOpJune2026Registry/HATS_IVOA_registry_Strasbourg_2026.pdf)

HATS and HiPS have similar architecture.

• Both concern an architecture with a service to acces the data.
• Both can be served by mirrors

List of metadata candidates for HATS (and HiPS)

• dataset Provenance:
  How to know if the registry record is the original? is a mirror? (address/country, provider, URL).

• Content: (Check relevance)

  • max-order, size ... (inform client about tiles volumetry ?)
  • describe tableset ? (for HATS and HiPS catalogue)

Proposals

• original archive : (for HATS+HiPS)
  use relationShip "Cites" (https://www.ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html)

• list mirrors: (HATS+HiPS)
  use element "vr:mirrorURL"

• provider :
  use vr:publisher for each mirror/original resource.
  Is it enough? (is relationShip enough?)

• address of the provider : (HATS+HiPS)
  vr:contact in the authority declaration (vg:Authority).

• hats_order: (HATS+HiPS)
  Deepest HATS order. Format: positive integer. it it interesting for registry?

• hats_estsize: (dataset size doesn't exists in registry)
  HATS size estimation. Format: positive integer. Unit : KB

• hats_nrows:
  vs:tableset attribute "nrows"

• hats_max_rows: only for HATS
  At catalog creation time, the maximum number of rows per file before breaking into 4 new files at higher order.

Declare Hats service

Similar to HiPS declaration. See The HiPS standard (https://ivoa.net/documents/HiPS/ section 5.3.1).
ex: ivo://CDS/P/Mars/MRO-CTX

Declare HATS capability in an existing vs:catalogueService resource.

eg: ivo://cds.vizier/I/355 (not available yet)

<capability standardID="ivo://ivoa.net/std/HATS">
    <interface xsi:type="vs:ParamHTTP">
        <accessURL use="base">https://vizcat.cds.unistra.fr/hats/gaia_dr3/</accessURL>
        <queryType>GET</queryType>
        <resultType>application/vnd.apache.parquet</resultType>
    </interface>
</capability>

[msdemlei]

On Mon, Jul 13, 2026 at 09:32:20AM -0700, gilleslandais wrote: gilleslandais created an issue (ivoa/registry-housekeeping#12) List of metadata candidates for HATS (and HiPS)

Thanks for putting this together. Let me put in a few comments:

- dataset Provenance: How to know if the registry record is the original? is a mirror? (address/country, provider, URL).

I'd like to avoid putting something like this into a capability type unless we have a strong reason to do so. If the resources come from different providers, I'd say the "mirrors" should just make IsIdenticalTo relationships to the original, and you'd know the original because it wouldn't have such a relationship. But is that good enough? That depends on what the use case is, and I wonder if this is well-defined.

- Content: (Check relevance) - max-order, size ... (inform client about tiles volumetry ?)

Is this relevant for discovery ("Give me HiPSes in the infrared with max-order larger than 14" does not sound implausible, but not very compelling either).

- describe tableset ? (for HATS and HiPS catalogue)

That seems to be a good idea, but fortunately (almost) everything for that is already there. We probably need a table reference inside of the capability, though.

# Proposals - original archive : (for HATS+HiPS) use relationShip "Cites" (https://www.ivoa.net/rdf/voresource/relationship_type/2016-08-17/relationship_type.html)

Plausible, yes.

- list mirrors: (HATS+HiPS) use element "vr:mirrorURL"

That would only work if the mirrors are run be the same publisher. But see above.

- provider : use vr:publisher for each mirror/original resource. Is it enough? (is relationShip enough?)

Unless we find a plausible case where it's not, I'd say it's enough.

- hats_estsize: (dataset size doesn't exists in registry) HATS size estimation. Format: positive integer. Unit : KB - hats_nrows: vs:tableset attribute "nrows"

What's the guiding query here? Size as a proxy for sensitivity? Hmmmm, not convinced. I think we should use better proxies.

- hats_max_rows: only for HATS At catalog creation time, the maximum number of rows per file before breaking into 4 new files at higher order.

Again, is there a discovery case for that?

# Declare Hats service Similar to HiPS declaration. See The HiPS standard (https://ivoa.net/documents/HiPS/ section 5.3.1). ex: ivo://CDS/P/Mars/MRO-CTX # Declare HATS capability in an existing vs:catalogueService resource. eg: ivo://cds.vizier/I/355 (not available yet) ``` <capability standardID="ivo://ivoa.net/std/HATS">

Yes, except I'd probably use HATS#table-1.0 or so for external consistency. So: Do we need an extension? Probably, if we want to match HATS-es with tables in the tableset. What needs to be in there? I'm not strongly convinced of anything beyond the table reference, frankly. And who will do it? I think for HATS the natural place would be the HATS REC that I think should be prepared in Apps. I'd volunteer for the registry section if necessary.

[gilleslandais]

I agree that it is better to reuse the existing (and making a new extension has a cost).
For instance provider information as well as the original archive could exploit the existing (based on relationship).
(I just discover that vr:mirrorURL is dedicated for the same publisher, so It can't be used for HATS provided in LSST and CDS)

If the resources come from different providers, I'd say the "mirrors"
should just make IsIdenticalTo relationships to the original, and
you'd know the original because it wouldn't have such a relationship.

And what about 2 ways (from mirror to original, from original to mirrors)
using isIdenticalTo for the both (if data are exactly the same of course).
We could also add "Cites" for the way mirror->original

About the content metadata (hats_estsize, hats_nrows,hats_max_rows).
They are certainly not usefull for search-discovery.
Those could be options in the registry (the values are in the HATS protocol in the partition_info.csv of the root URL) as information (like the vs:nrows for TAP access) before downloading potentially huge volumetry.
May be using vs:nrows (=hats_nrows) in vs:table is enough?

So: Do we need an extension? Probably, if we want to match HATS-es
with tables in the tableset.

Linking capability and tableset could be used by other protocols than HATS & HiPS .
Note that I anticipate a little , because today the HiPS catalogue records (in CDS) doesn't include the tableset (eg: https://cds.unistra.fr/registry/?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://CDS/C/CALIFA/V500/DR2)

What needs to be in there? I'm not strongly convinced of anything
beyond the table reference, frankly.

And who will do it? I think for HATS the natural place would be the
HATS REC that I think should be prepared in Apps. I'd volunteer for
the registry section if necessary.

to see with HATS editors

[tsdower]

If the resources come from different providers, I'd say the "mirrors"
should just make IsIdenticalTo relationships to the original, and
you'd know the original because it wouldn't have such a relationship.

And what about 2 ways (from mirror to original, from original to mirrors) using isIdenticalTo for the both (if data are exactly the same of course). We could also add "Cites" for the way mirror->original

I think for true mirrors, IsIdenticalTo works for our purposes, and cites could give a directionality hint that would otherwise be left to description text and human determination. (If we ever link back from source->mirror resources. That would be nice.)

This also lets us use IsDerivedFrom for not-quite-true mirrors with small schema changes. The "cites" hint would be less useful here but still could be added. I can't think of any HiPS or HATS examples off the top of my head, mind you. It is a problem we run into with some popular catalogs in general, though.

I am not sold that we get much out of the other hats_xxx proposed fields and prefer a simpler extension if we can. If anyone has a good search use case, I can be easily convinced.

[gilleslandais]

To summarize ,
Unless explicitly asked by HATS provider, we can reuse the existing (no new extensions).

• use vr:publisher to put the provider
• use relationShip to link original, copy or derived product
  • Cites: to indicate original product (and to give a directionality)
  • IsIdenticalTo: for copy (can be used for original or mirror).
  • (or) IsDerivedFrom: derived product
• use vs:nrows (element in vs:table) to indicate number of records

[msdemlei]

On Mon, Aug 03, 2026 at 08:41:37AM -0700, gilleslandais wrote: gilleslandais left a comment (ivoa/registry-housekeeping#12) To summarize , Unless explicitly asked by HATS provider, we can reuse the existing (no new extensions).

I would tend to agree and hence close this issue. What's still somewhat open is the matchup between a hats capability and the table(s) in the tableset. Let's talk about that over in VODataService, I'd say. Although: Would table : capability be 1 : 1 in HATS or can a HATS contain multiple tables?

[gilleslandais]

multiple table exists ! :) (Gaia in VizieR for instance)

We can suggest the VODataService capability (with param/stats) to the HATS team. They have a meeting in September - we could ask to join them.

[msdemlei]

On Wed, Aug 05, 2026 at 12:11:10AM -0700, gilleslandais wrote: gilleslandais left a comment (ivoa/registry-housekeeping#12) multiple table exists ! :) (Gaia in VizieR for instance)

I understand correctly that this means that there are multiple tables within a single HATS? You see, we could be defining a type vs:TableReferencingCapability with the content model validationLevel* description? interface* forTable? (cf. http://docs.g-vo.org/schemadoc/schemas/VOResource_xsd/complexTypes/Capability.html for the basic vr:Capability; this needs to be in vs: rather than vr: because vs defines the tableset). This would then probably cover HATS and HiPS according to what we've gathered in terms of requirements for them; and if it's not enough, we could still derive more specialised capability types from there. If, however, we actually have multiple tables in a single HATS, that content model would need to be validationLevel* description? interface* forTable*

We can suggest the VODataService capability (with param/stats) to the HATS team. They have a meeting in September - we could ask to join them.

I don't think param/stats would work for HATS and HiPS because they don't have anything like SCS2's TABLE parameter. Or do they?

[gilleslandais]

I understand correctly that this means that there are multiple tables
within a single HATS?

We provide in CDS one HATS for one table . But in the same catalogue , there are possibly different HATS.

About HATS server:
HATS spec describes the architecture of a single table and not a server (I don't think there is a section like HiPS server)
but :) , Francois-Xavier built a HATS server that provides some VizieR tables. This server doesn't use TABLE param but uses instead a REST-like URL: something like https://vizcat.cds.unistra.fr/hats/{TABLE}/

You see, we could be defining a type vs:TableReferencingCapability
with the content model

I glimpse here something interestintg (that's the inverse direction of the VODataService PR)

(cf.
http://docs.g-vo.org/schemadoc/schemas/VOResource_xsd/complexTypes/Capability.html
for the basic vr:Capability; this needs to be in vs: rather than vr:
because vs defines the tableset).

? a little bit obscure for me :(

I don't think param/stats would work for HATS and HiPS because they
don't have anything like SCS2's TABLE parameter. Or do they?

No it doesn't exist. But we can suggest (for HATS which is not a standard yet) to have a paragraph with a "HATS server" and which could have a TABLE parameter?

[msdemlei]

On Wed, Aug 05, 2026 at 05:39:47AM -0700, gilleslandais wrote: gilleslandais left a comment (ivoa/registry-housekeeping#12) > I understand correctly that this means that there are multiple tables > within a single HATS? We provide in CDS one HATS for one table . But in the same catalogue , there are possibly different HATS.

With catalogue, you mean "VO resource"? If so, that's exactly what we want to fix here. What I try to figure out here is whether capability to table will be 1:1 or 1:n (with the latter opening a can of worms down the road).

> (cf. > http://docs.g-vo.org/schemadoc/schemas/VOResource_xsd/complexTypes/Capability.html > for the basic vr:Capability; this needs to be in vs: rather than vr: > because vs defines the tableset). ? a little bit obscure for me :(

That was just an excuse for putting this relatively fundamental type into VODataService rather than VOResource.

> I don't think param/stats would work for HATS and HiPS because they > don't have anything like SCS2's TABLE parameter. Or do they? No it doesn't exist. But we can suggest (for HATS which is not a standard yet) to have a paragraph with a "HATS server" and which could have a TABLE parameter?

If it's easy to do, let's adapt the Registry to protocols and discovery patterns rather than the other way round. And I think in this case it's reasonably easy to do.