HiPS standardization - next step...

[Markus Demleitner]

Hi Pierre, hi Thomas,

On Wed, Mar 30, 2016 at 03:42:05PM +0200, Thomas Boch wrote:
> 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.

I agree with these two assessements -- and I believe the resolution
of creator DIDs is beyond what the Registry should do (in the
forseeable future).

For creator DIDs, the Registry's role is just ensuring the uniqueness
of the identifiers so far.

That doesn't mean individual standards can prescribe ways to resolve
creatorDIDs.  HiPS does, for instance, with its HiPS servers.  Which
is fine for "smart" HiPS clients.  

As Thomas says, there may be other possible uses.

The primary scenario I can see is: A scientist looks for a resource
by some content-based constraint -- say, infrared images in a certain
band, region, and time span.  She discovers five resources and now
wants to get an idea of the services' contents.  Rather than pulling a
few sample images, she sees that there are HiPSes for the services,
and she just pulls these into an appropriate HiPS client.

I suggest that for this basic usage the "root URL" of the HiPS would
be enough.  This would lead to a simple capability the publishers add
to *their* registry record; users and clients could tell it's a HiPS
because of this standardID:

  <capability standardID="ivo://ivoa.net/std/hips#hips-1.0">
    <!-- [the actual identifier might be different, this is just a
    sketch -->
    <interface role="std" xsi:type="vs:ParamHTTP">
      <accessURL use="base">http://example.com/my-hips</accessURL>
    </interface>
  </capabiltiy>

If there's a media type for HiPS (is there?), you could add a

<resultType>application/x-hips</resultType>

(or whatever) to the interface element.

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

Exactly -- this is what the above proposal manages.

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

If this use case is found to be important, the most straightforward
way would be to  define a registry extension that would let you give
the HiPS's creatorDID:

  <capability standardID="ivo://ivoa.net/std/hips#hips-1.0"
      xsi:type="hips:HIPS">

    <!-- this is pure fantasy at this point: -->
    <creatorDID>ivo://ESAVO?HERSCHEL/PACS-color</creatorDID>

    <interface role="std" xsi:type="vs:ParamHTTP">
      <accessURL use="base">http://example.com/my-hips</accessURL>
    </interface>
  </capabiltiy>

Clients that don't actually know much about HiPS could use the access
URL given, smarter clients could pull the creatorDID out of this
record and go to the HiPS server to find mirrors.

My (not terribly informed) take: Probably not worth it for version 1.

Finally, it's possible to have the mirrors declared using multiple
interfaces.  But since the mirrors are typically run by different
publishers (as far as I know), I'd not like that -- it's against the
"the publisher controls all the registry content about his/her
resources[1]" motto we have in the Registry right now and would be
hard to maintain even if we were willing to soften that stance.

Cheers,

          Markus


[1] Terms and conditions apply.  Well, actually, the only exception
is the validationLevel element.  And, if you really are picky, perhaps
relationship.