<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
Dear IVOA members,<br>
<br>
In the current effort to standardize HiPS we are facing to a tricky
issue with the <a moz-do-not-send="true"
href="http://www.ivoa.net/documents/IVOAIdentifiers/20150709/PR-Identifiers-2.0-20150709.pdf">PR-Identifiers2.0
IVOA doc</a> about IVOID, and notably the constraint mentioned in
section 2.4 <i>"</i><a moz-do-not-send="true" id="tth_sEc2.4"><i><b>IVOIDs</b>
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, <b>MUST always be dereferenceable</b>,
i.e., resolve in the VO Registry."<br>
<br>
<br>
</i><b>The problem:</b><i><br>
</i><br>
Last week, we started the process of the IVOA HiPS
standardization, notably by homogeneizing their identifiers
already used by the HiPS providers.<br>
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.<br>
<br>
<br>
<i>HiPS IVORN examples with their associated properties</i><br>
</a>
<ol>
<li><a moz-do-not-send="true"
href="http://cade.irap.omp.eu/documents/Ancillary/4Aladin/DIRBE_ZSMA_8/properties">ivo://ov-gso/P/DIRBE/ZSMA8</a>
: Band8 of COBE HiPS provided by IRAP<br>
</li>
<li><a moz-do-not-send="true"
href="http://axel.u-strasbg.fr/HiPSCatService/I/284/out/properties">ivo://CDS.VizieR/I/284/out</a>
: HiPS of the table "out" of the I/234 catalog (USNOB1) provided
by CDS</li>
<li><a moz-do-not-send="true"
href="http://alasky.u-strasbg.fr/HST-raid8/2015.12.16/filter_B_hips/properties">ivo://cadc.nrc.ca/P/HST-B</a><a
moz-do-not-send="true" id="tth_sEc2.4"> : HiPS of B band of
the HST generated by the CADC and distributed by CDS<br>
</a></li>
<li><font color="#006600">ivo://CDS.Aladin/2016/A+A/585/123/hips1</font>
: Specifical HiPS associated to the publication
2016A+A..585..123 (not yet public)<br>
</li>
<li>i<font color="#006600">vo://eso.org/outreach/eso1238a</font> :
HiPS of the outreach image 1238a generated by ESO outreach
department (prototype)<br>
</li>
<li>see others <a moz-do-not-send="true"
href="http://aladin.unistra.fr/hips/list">here</a> ("more"
links)</li>
</ol>
<p><a moz-do-not-send="true" id="tth_sEc2.4">In a few months, we
will have about 20000 HiPS available (tables with coordinates
[15000?] + survey bands [500] + specifical HiPS images
[>4000])<br>
</a></p>
<p><a moz-do-not-send="true" id="tth_sEc2.4"> 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:<br>
</a></p>
<a moz-do-not-send="true" id="tth_sEc2.4">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 "<b>ivo:/AUTH-ID/HIPS-ID</b>" 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, <b>most of the HiPS IVOIDs will never be valid
as they will never be described individually in the VO registry
</b>(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)<br>
<br>
<br>
<b>The reality:</b><br>
<br>
It seems that we can not continue to use IVOID IVOA identifier
mechanism for HiPS<br>
<br>
<b><br>
Three solutions </b></a>
<ol>
<li><a moz-do-not-send="true" id="tth_sEc2.4">
<p xmlns="http://www.w3.org/1999/xhtml" class="parsep"><span>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 </span><a
href="http://ivoa.net/documents/Notes/DataCollect">discovery
resource note)</a></p>
</a><a moz-do-not-send="true" id="tth_sEc2.4"></a><a
moz-do-not-send="true" id="tth_sEc2.4"><span></span></a></li>
<li><a moz-do-not-send="true" id="tth_sEc2.4"><span>Modify the
HiPS identification by trying to use the new "fragment"
syntax introduced in the new </span>PR-Identifiers2.0. For
instance, replace<font color="#006600">
ivo://CDS.VizieR/I/284/out</font> by <font color="#006600">ivo://CDS.VizieR/I/284?<i>some_keyword</i>=out</font>.
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
<font color="#006600">I/284/out</font> and not <font
color="#006600">I/284?<i>some_keyword</i>=out</font>. Does
it means that CDS VizieR and associated clients have to
support both, or remove the usage of previous one ? I suppose
no.<br>
<br>
</a></li>
<li>Accept the definition of an IVOID not necessary declared in
the VO registry. <br>
<br>
</li>
</ol>
<p><b>Pragmatic approach:</b><br>
</p>
<p>In fact, I suppose that a pragmatic approach could use the 3
solutions simultaneously depending of each case. <br>
</p>
<ol>
<li>Add VizieR tables in the VO Registry for avoiding to break the
VizieR notation (=> <a moz-do-not-send="true"
id="tth_sEc2.4"><font color="#006600">
ivo://CDS.VizieR/I/284/out</font> would be valid)</a></li>
<li><a moz-do-not-send="true" id="tth_sEc2.4">Use fragment IVOID
for really "too small resources" level, notably the HiPS
outreach images (i<font color="#006600">vo://eso.org/outreach?product=eso1238a</font>)</a></li>
<li><a moz-do-not-send="true" id="tth_sEc2.4">Tolerate the
existence of IVOIDs not yet defined in the registry notably
for new HiPS providers (=><font color="#006600"> ex:
ivo://JAXA/xxx</font>), 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)</a></li>
</ol>
<p><br>
</p>
<p><b>Conservative HiPS temporary solution</b><b><br>
</b></p>
<p>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)...<br>
</p>
<p>In the mean time, and for avoiding to jam the HiPS IVOA
standardization process during this discussion<font
color="#006600"> I suggest to stop the usage of IVOID in the
"properties" HiPS file (<i>publisher_did</i> field), and use
instead two new fields splitting the authority-id and the
hips-id in two separated fields (<i>p</i><i>ublisher_id</i> and
<i>hips_id</i>)</font>. 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.<br>
</p>
<p><br>
</p>
<p>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.<br>
</p>
<p>Best regards<br>
Pierre Fernique</p>
<br>
</body>
</html>