<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Pierre, hi all,<br>
<br>
Regarding your 3 propositions about registration of individual
HiPS:<br>
<br>
#0 is the simplest but it prevents discovery of individual HiPS by
"basic" registry clients. Discovery would then be delegated to
ad-hoc clients knowing how to query HiPS servers. This seems a
pity, given the registry already provides the infrastructure for
basic search.<br>
<br>
#1 sounds a bit odd. It would mean that each HiPS creator has to
track every mirror, monitor potential changes in the mirrors root
URL, etc and reflect those changes in its resource declaration. It
does not feel right to me to declare interfaces you do not manage.<br>
Plus, contact email would be the same for all mirrors, which is
strange. If things go awry on the CDS mirror of Herschel HiPS, why
would ESAC be contacted? Responsibilities are blurred within this
scheme.<br>
<br>
as for #2 : the curation element in VO resource could help. It is
made up of publisher and creator. Publisher has an ivo-id
attribute, but unfortunately creator is missing this attribute.
Thus, I'm not really sure how we would refer to the IVOID (<tt>ivo://ESAVO?HERSCHEL/PACS-color</tt><tt>)
</tt>of the HiPS. Has any registry expert a suggestion for this?<br>
<br>
To summarize my point of view: we should at least allow and let
HiPS creators declare their individual HiPS with the associated
master URL, as this would allow for discovery of HiPS through
RegTAP for instance.<br>
In a second step, it would be nice if we could find a solution
within the current registry infrastructure to also allow for
proper declaration of HiPS mirrors (with proper description of the
creator etc) but I can live without that since mirrors could
potentially be discovered by specialized clients querying directly
HiPS servers.<br>
<br>
I'd be interested in reading the opinion of other HiPS creators
and providers.<br>
<br>
Cheers,<br>
<br>
Thomas<br>
<br>
Le 29/03/2016 19:07, Pierre Fernique a écrit :<br>
</div>
<blockquote cite="mid:56FAB669.2090407@astro.unistra.fr" type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<br>
Dear HiPS contributors,<br>
<br>
The process of the HiPS IVOA standardization is progressing.<br>
Here the state of the debates. <br>
<br>
<b>The agreement:</b><b><br>
</b><br>
As you read on the App mailing list we reached a "global
agreement" on these three following points:<br>
<ol>
<li>Usage of<font color="#006600"> a valid IVOID</font> to
identify each HiPS via a "creator identifier" (either, already
defined in the VO registry, or -by default - following this
syntax: ivo://authority_id?obs_id)</li>
<li>This identifier will be stored under the HiPS properties key
word: <font color="#006600">creator_did</font></li>
<li>Each HiPS provider may declare their<font color="#006600">
HiPS server</font> in the VO registry (a HiPS server
provides HiPS + the list of these HiPS
(identifier/baseURL/status/date for each HiPS - master and
mirror copies))<br>
</li>
</ol>
<p>These 3 components are sufficient to operate a functional "HiPS
network" (cf functional diagram below / ASTERICS EURO-VO
presentation Edinburgh March 2016). These components are being
implemented with the deployement of the HiPS list of the HiPS
creators (CDS, ESAC, JAXA, IRAP, IAS, ...), the usage of the
MocServer for aggregating the HiPS lists (<a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://aladin.u-strasbg.fr/hips/list"><a class="moz-txt-link-freetext" href="http://aladin.u-strasbg.fr/hips/list">http://aladin.u-strasbg.fr/hips/list</a></a>),
and Aladin Desktop, Aladin Lite and MIZAR as HiPS clients. And
it works !<br>
</p>
<p>Concerning the point 3, Markus Demleitner and myself, we
prepared together the HiPS VO standard ID record (see below) for
defining the HiPS protocol IVOID labels. I will register it in
the VO registry asap in order to allow each HiPS provider to
declare their HiPS server in the VO registry.<br>
</p>
<p>Now, next point...<br>
</p>
<p><br>
<b>The next question:</b><b> </b><b><br>
</b></p>
<p>One point is still in debate (indenpently to the 3 points
above)<b> </b>:<br>
</p>
<p><font color="#006600"><i>Do we also allow the VO registry
declaration of individual HiPS as individual "resource" ?
(to correctly catch this point, you may do the parallel with
the declaration of VizieR (and clone of VizieR) - as catalog
servers - and the declaration of each individual catalog -
as resources).</i></font></p>
<p><font color="#006600"><i>And if we say yes, does this
declaration have to be done by the <b>creator</b> of the
HiPS ? or by the <b>publisher(s)</b> of the HIPS ?</i><i><br>
</i></font></p>
<p><u><i>A concrete case:<br>
<br>
</i></u>ESAC created a HiPS for HERSCHEL observations. This
HiPS has been mirrored on CDS. Both sites are publishing this
HiPS.<br>
</p>
<p><i>Solution 0:</i> No need to declare this HiPS as individual
resource, HiPS server lists (see above) do the job !<br>
</p>
<p><i>Solution 1</i>: Only ESAC is authorized to declare this HiPS
in the VO registry, with two interfaces <br>
<tt> => ivo://ESAVO/HERSCHEL/PACS-color</tt><tt><br>
</tt><tt> A color composition using all public PACS
observations from the Herschel Science Archive....</tt><tt><br>
</tt><tt> interface1: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://skies.esac.esa.int/Herschel/PACS-color">http://skies.esac.esa.int/Herschel/PACS-color</a></tt><tt><br>
</tt><tt> interface2: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://alasky.u-strasbg.fr/ESAC/ESAVO_P_HERSCHEL_PACS-color">http://alasky.u-strasbg.fr/ESAC/ESAVO_P_HERSCHEL_PACS-color</a></tt></p>
<p><i>Solution 2</i> : Both ESAC and CDS are authorized to declare
independently this HiPS in the VO registry, <br>
<tt> => ivo://ESAVO/HERSCHEL/PACS-color</tt><tt><br>
</tt><tt> </tt><tt>A color composition using all public
PACS observations from the Herschel Science Archive....</tt><tt><br>
</tt><tt> creator: ivo://ESAVO?HERSCHEL/PACS-color</tt><tt><br>
</tt><tt> interface: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://skies.esac.esa.int/Herschel/PACS-color">http://skies.esac.esa.int/Herschel/PACS-color</a></tt></p>
<p><tt> => ivo://CDS/Herschel-PACS-color</tt><tt><br>
</tt><tt> Herschel </tt><tt><tt>PACS </tt>colored HiPS
composition....</tt><tt><br>
</tt><tt> creator: ivo://ESAVO?HERSCHEL/PACS-color</tt><tt><br>
</tt><tt> interface: </tt><tt><a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://alasky.u-strasbg.fr/ESAC/ESAVO_P_HERSCHEL_PACS-color">http://alasky.u-strasbg.fr/ESAC/ESAVO_P_HERSCHEL_PACS-color</a></tt></p>
<p>Both usages are VO valid. Both solutions have their
advantages/disadvantages:<br>
</p>
<ul>
<li>The solution 0 will work and it is obviously the simplest.
But, to be coherent, why are we keeping VizieR catalog
individual definitions in the VO registry ? Disallow the VO
registry resource declaration level would be a big evolution
of the VO registry usage.<br>
</li>
<li>The solution 1 has only one ID concept : the creator id (no
publisher notion). It is quite easy to explain, and it is
fully coherent with the HiPS identifier. However, it implies
that the HiPS creator will have the charge to update his
record each time a new HiPS site distributes this HiPS. Also,
it implies that we start to manipulate the "creator" notion in
the VO registry. That's not a revolution but probably an
evolution.<br>
</li>
<li>At the opposite, the solution 2 introduces the notion of
HiPS publishers in addition of the HiPS creator. That means
that we will probably have to extend the VO registry record
schema for storing properly the definition of the HiPS creator
ID, notably to be able to know that these two resources are
the same HIPS and to avoid to let believe (in solution 2 -
record b) that this HiPS has been created by CDS. Also the
description/meta-data associated to the resource will be
duplicated, and there is no guarantee that both declarations
will be identical/coherent...<br>
<br>
</li>
<li>Additionnally, concerning solution 1 and 2, and related to
the recent Markus and Mark's IVOA note (<a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://ivoa.net/documents/Notes/DataCollect"><a class="moz-txt-link-freetext" href="http://ivoa.net/documents/Notes/DataCollect">http://ivoa.net/documents/Notes/DataCollect</a></a>),
we could have to study if it is possible and recommended to
link these individual resource declarations with their HiPS
servers ("served-by" links + auxiliary tagging). Quite easy in
solution 1, probably harder in solution 2.<br>
</li>
</ul>
<p>So, HiPSers, what is your point of view ? Solution 0, 1 or 2 ?<br>
</p>
<p>Thanks for your ideas, and contributions.<br>
Pierre Fernique<br>
</p>
<p>PS. This technical mail exchange will be probably tricky to
follow. May I ask to all participants to keep in mind that all
listeners are not necessary english native speaking people
(definitively my case). It could help a lot if we try to use
simple vocabulary and direct sentences, with examples. Thanks
(at least on my own behalf). </p>
<p>--<br>
</p>
<p><i>HiPS network functional diagram</i><i><br>
</i></p>
<p><img src="cid:part7.06030808.01060401@astro.unistra.fr" alt=""><br>
<br>
</p>
<p><i>HiPS Standard ID definition</i><i><br>
</i></p>
<p><img src="cid:part8.04090700.05040004@astro.unistra.fr" alt=""></p>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Thomas Boch
Ingénieur de Recherche
CDS/Observatoire Astronomique Phone : 33 (0)3 68 85 24 42
11, rue de l'Universite Fax : 33 (0)3 68 85 24 17
F-67000 Strasbourg Email : <a class="moz-txt-link-abbreviated" href="mailto:thomas.boch@astro.unistra.fr">thomas.boch@astro.unistra.fr</a>
France <a class="moz-txt-link-freetext" href="http://cdsweb.u-strasbg.fr/~boch">http://cdsweb.u-strasbg.fr/~boch</a>
</pre>
</body>
</html>