HiPS standardization - next step...
Thomas Boch
thomas.boch at astro.unistra.fr
Wed Mar 30 15:42:05 CEST 2016
Hi Pierre, hi all,
Regarding your 3 propositions about registration of individual HiPS:
#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.
#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.
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.
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 (ivo://ESAVO?HERSCHEL/PACS-color)
of the HiPS. Has any registry expert a suggestion for this?
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.
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.
I'd be interested in reading the opinion of other HiPS creators and
providers.
Cheers,
Thomas
Le 29/03/2016 19:07, Pierre Fernique a écrit :
>
> Dear HiPS contributors,
>
> The process of the HiPS IVOA standardization is progressing.
> Here the state of the debates.
>
> *The agreement:**
> *
> As you read on the App mailing list we reached a "global agreement" on
> these three following points:
>
> 1. Usage ofa valid IVOID 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)
> 2. This identifier will be stored under the HiPS properties key word:
> creator_did
> 3. Each HiPS provider may declare theirHiPS server 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))
>
> 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 (http://aladin.u-strasbg.fr/hips/list), and Aladin Desktop,
> Aladin Lite and MIZAR as HiPS clients. And it works !
>
> 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.
>
> Now, next point...
>
>
> *The next question:****
> *
>
> One point is still in debate (indenpently to the 3 points above)**:
>
> /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)./
>
> /And if we say yes, does this declaration have to be done by the
> *creator* of the HiPS ? or by the *publisher(s)* of the HIPS ?//
> /
>
> _/A concrete case:
>
> /_ESAC created a HiPS for HERSCHEL observations. This HiPS has been
> mirrored on CDS. Both sites are publishing this HiPS.
>
> /Solution 0:/ No need to declare this HiPS as individual resource,
> HiPS server lists (see above) do the job !
>
> /Solution 1/: Only ESAC is authorized to declare this HiPS in the VO
> registry, with two interfaces
> => ivo://ESAVO/HERSCHEL/PACS-color
> A color composition using all public PACS observations from
> the Herschel Science Archive....
> interface1: http://skies.esac.esa.int/Herschel/PACS-color
> interface2:
> http://alasky.u-strasbg.fr/ESAC/ESAVO_P_HERSCHEL_PACS-color
>
> /Solution 2/ : Both ESAC and CDS are authorized to declare
> independently this HiPS in the VO registry,
> => ivo://ESAVO/HERSCHEL/PACS-color
> A color composition using all public PACS observations from the
> Herschel Science Archive....
> creator: ivo://ESAVO?HERSCHEL/PACS-color
> interface: http://skies.esac.esa.int/Herschel/PACS-color
>
> => ivo://CDS/Herschel-PACS-color
> Herschel PACS colored HiPS composition....
> creator: ivo://ESAVO?HERSCHEL/PACS-color
> interface:
> http://alasky.u-strasbg.fr/ESAC/ESAVO_P_HERSCHEL_PACS-color
>
> Both usages are VO valid. Both solutions have their
> advantages/disadvantages:
>
> * 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.
> * 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.
> * 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...
>
> * Additionnally, concerning solution 1 and 2, and related to the
> recent Markus and Mark's IVOA note
> (http://ivoa.net/documents/Notes/DataCollect), 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.
>
> So, HiPSers, what is your point of view ? Solution 0, 1 or 2 ?
>
> Thanks for your ideas, and contributions.
> Pierre Fernique
>
> 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).
>
> --
>
> /HiPS network functional diagram//
> /
>
>
>
> /HiPS Standard ID definition//
> /
>
--
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 : thomas.boch at astro.unistra.fr
France http://cdsweb.u-strasbg.fr/~boch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20160330/6c7c4a5d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 156738 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20160330/6c7c4a5d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 39642 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20160330/6c7c4a5d/attachment-0003.png>
More information about the apps
mailing list