HiPS standardization - next step...

Pierre Fernique Pierre.Fernique at astro.unistra.fr
Tue Mar 29 19:07:53 CEST 2016 

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//
/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20160329/af040480/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bdgadieh.png
Type: image/png
Size: 156738 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20160329/af040480/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cbcbeebj.png
Type: image/png
Size: 39642 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20160329/af040480/attachment-0003.png>

More information about the apps mailing list