HiPS IVOID issue

[Pierre Fernique]

Dear IVOA members,

In the current effort to standardize HiPS we are facing to a tricky 
issue with the PR-Identifiers2.0 IVOA doc 
<http://www.ivoa.net/documents/IVOAIdentifiers/20150709/PR-Identifiers-2.0-20150709.pdf> 
about IVOID, and notably the constraint mentioned in section 2.4 
/"//*IVOIDs* are used to identify resources in the general sense, i.e., 
they might refer to datasets, abstract concepts, etc.; their Registry 
parts, on the other hand, *MUST always be dereferenceable*, i.e., 
resolve in the VO Registry."


/*The problem:*/
/
Last week, we started the process of the IVOA HiPS standardization, 
notably by homogeneizing their identifiers already used by the HiPS 
providers.
In the existing implementation, HiPS are already identified by an IVORN 
following the last IVOA recommendation, normally it should have been 
easy to adjust the authority-id (first word of the IVORN) which the 
corresponding one in the VO registry or by creating the missing 
authority-id in the VO registry and that's all.


/HiPS IVORN examples with their associated properties/

 1. ivo://ov-gso/P/DIRBE/ZSMA8
    <http://cade.irap.omp.eu/documents/Ancillary/4Aladin/DIRBE_ZSMA_8/properties>
    : Band8 of COBE HiPS provided by IRAP
 2. ivo://CDS.VizieR/I/284/out
    <http://axel.u-strasbg.fr/HiPSCatService/I/284/out/properties> :
    HiPS of the table "out" of the I/234 catalog (USNOB1) provided by CDS
 3. ivo://cadc.nrc.ca/P/HST-B
    <http://alasky.u-strasbg.fr/HST-raid8/2015.12.16/filter_B_hips/properties> 
    : HiPS of B band of the HST generated by the CADC and distributed by CDS
 4. ivo://CDS.Aladin/2016/A+A/585/123/hips1 : Specifical HiPS associated
    to the publication 2016A+A..585..123 (not yet public)
 5. ivo://eso.org/outreach/eso1238a : HiPS of the outreach image 1238a
    generated by ESO outreach department (prototype)
 6. see others here <http://aladin.unistra.fr/hips/list> ("more" links)

In a few months, we will have about 20000 HiPS available (tables with 
coordinates [15000?] + survey bands [500] + specifical HiPS images [>4000])

Last days, CDS VizieR people (Sebastien Derriere and Thomas Boch), and 
CADC people (Daniel Durand and Pat Dowler) have alerted me about the 
following problem:

If we want to apply the new version of the IVOA identifier 
recommendation, and notably the strong constraint of the section 2.4, we 
are no longer able to use the simple previous scheme 
"*ivo:/AUTH-ID/HIPS-ID*" IVOID syntax (new name for IVORN). Simply 
because there is presently no HIPS described in the VO registry, so all 
these IVOIDs are invalid. But more, *most of the HiPS IVOIDs will never 
be valid as they will never be described individually in the VO registry 
*(catalog tables ? outreach individual images ? HiPS associated to an 
article ?) Additionnally,  during the last IVOA meeting, we were 
thinking to add HiPS in the VO registry as a new capability, and not 
necessary as a new separated VO entry (comparable to a cone search or a 
TAP access point for a dedicated resource)


*The reality:*

It seems that we can not continue to use IVOID IVOA identifier mechanism 
for HiPS

*
Three solutions *

 1.

    Declare all resources having a HiPS access in the VO registry
    notably all VizieR tables (and not only catalogs), plus all outreach
    images, ... Does it technically and politically possible ? May be by
    populating the VO registry automatically from the global HiPS list
    (http://aladin.unistra.fr/hips/list -> VO registry). But the
    delegation of VO record creation/update has never been studied yet
    and the level of granularity of the VO ressource definitions will
    probably introduce structural incoherences (HiPS table level on one
    side, and catalog description on other side, HiPS per band survey,
    and not HiPS per survey... this point is clearly related to the last
    Markus's discovery resource note)
    <http://ivoa.net/documents/Notes/DataCollect>

 2. Modify the HiPS identification by trying to use the new "fragment"
    syntax introduced in the new PR-Identifiers2.0. For instance,
    replaceivo://CDS.VizieR/I/284/out by
    ivo://CDS.VizieR/I/284?/some_keyword/=out. Unfortunately, this
    solution will also mean to adapt the internal service nomenclature
    if they already use the previous IVORN "/" separator and not the
    "?something" new syntax. For instance, the notation for tables in
    VizieR and all VizieR clients (Aladin, TOPcat, DS9, Web sites...)
    used for years is I/284/out and not I/284?/some_keyword/=out. Does
    it means that CDS VizieR and associated clients have to support
    both, or remove the usage of previous one ? I suppose no.

 3. Accept the definition of an IVOID not necessary declared in the VO
    registry.

*Pragmatic approach:*

In fact, I suppose that a pragmatic approach could use the 3 solutions 
simultaneously depending of each case.

 1. Add VizieR tables in the VO Registry for avoiding to break the
    VizieR notation (=> ivo://CDS.VizieR/I/284/out would be valid)
 2. Use fragment IVOID for really "too small resources" level, notably
    the HiPS outreach images (ivo://eso.org/outreach?product=eso1238a)
 3. Tolerate the existence of IVOIDs not yet defined in the registry
    notably for new HiPS providers (=>ex: ivo://JAXA/xxx), and/or accept
    the creation of VO registry entries by delegation (the ivo:JAXA/xxx
    VO registry would be generated from its properties HiPS definitions)


*Conservative HiPS temporary solution**
*

Beyond this actual HiPS context, I suppose that we will need time to 
discuss if an IVOID can be used or not outside its VO registry 
existence, and which level of granularity we want in the VO registry 
(related to the last Markus' note)...

In the mean time, and for avoiding to jam the HiPS IVOA standardization 
process during this discussionI suggest to stop the usage of IVOID in 
the "properties" HiPS file (/publisher_did/ field),  and use instead two 
new fields splitting the authority-id and the hips-id in two separated 
fields (/p//ublisher_id/ and /hips_id/). This solution would allow to 
continue to have a usable and homogeneous identification HiPS mechanism 
without clashing with the 2.4 constraint, but allowing to generate the 
associated IVOID (ivo:// prefix + concatenation with "/" separator) if 
the associated HiPS is really defined in the VO registry.


For the end, I have to apologize for arriving so late in the document 
Identifier process (PR state). But I have to say that I had totally 
missed the consequence of the 2.4 contraint until this practical case of 
the HiPS IVOA standardization raised it.

Best regards
Pierre Fernique


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20160115/1f310201/attachment.html>