HiPS IVOID issue => proposed solution

[Markus Demleitner]

Hi Pierre,

On Fri, Jan 29, 2016 at 05:09:46PM +0100, Pierre Fernique wrote:
> So it is not possible to use directly IVOID syntax (1- to avoid the "a
> priori" VO registry declaration, 2-the IVOID syntax depends now to the way
> that this declaration is done, 3-the VO registry ambiguity between publisher
> and creator). However by basing the HiPS identification on the pair of ids
> creator_id and obs_id, I think that we can ensure compatibility with VO

While I cannot keep you from inventing new identifier schemes, I
think none of these points actually makes this necessary, and since
I'm a big fan of a "make as few standards as possible (but as many as
necessary)", I'll try to convince you again:

Ad (1) To create IVOID-based creatorDIDs, creators would just have to
register their existence as organisations, *not* each HiPS.  The
HiPSes they can make as public or secret as they like. With
creatorDIDs, the Registry just provides the serivce of ensuring
uniqueness of creator authorities to you.  So, people wanting to mint
ids would only have to provide a Registry record like this:

http://dc.zah.uni-heidelberg.de/rr/q/pmh/pubreg.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo%3A%2F%2Fiap.fr%2Fiap

-- which I'd claim is not unreasonable, in particular if you offer a
pre-made authority (ivo://hips, say) to them so they can, if they
don't already have an authority, simply grab ivo://hips/myinst and be
done with it).  I'm happy to advise/contribute standards
test/whatever else might be necessary.

If you don't use that, you'll have to provide some analogous
infrastructure (or how else would you ensure that no two creators
will use the same id?) -- and that, I think, would be an unnecessary
duplication of efforts.

Ad (2) Creators are certainly free to do whatever they want after the
question mark -- but how is that a problem?  Do clients actually
parse these identifiers?  More deeply than perhaps separating the
Registry part and the local part?

Ad (3) There is no ambiguity.  It's just two different things.  The
creator id is a bit like a manufacturer's serial number.  It took me
a while to realise that that's what you were after in HiPS, which
admittedly was a bit dense of me given this id is embedded in the
file.

Just like a car has a manufacturer number somewhere on its chassis
*and* a license plate, a dataset can have multiple ids.  Just as your
traffic authority issues license plates (and quite possibly several
in succession for the same car as it changes hands), the publisher
DID can be issued by a publisher, i.e., the person running the
service that hands out a piece of data (e.g., when serving the
dataset from SIAv2 or ObsTAP services).  But that's something you
only need to worry about when you're talking about access protocols.

Within HiPS, you should only worry about the creator DIDs (the chassis
number).

> So, concretly the HiPS provider will have the choice :
> 1) to not declare their HiPSes in the VO (for tests, political choice, not
> really related to the VO, or ...)

So, what I'm arguing above is that they're free to do so whether or
not you use the Registry to manage the creator's organisation
records.  And as I said, you can still offer an ivo://hips/test
organisation record for quick hacks.

> 2) to declare their HiPS individually thanks to the appropriated capability
> that you suggest (thanks for that). In this case the associated IVOID would
> be ivo://creator_id <ivo://creator_id/obs_id>/
> <ivo://creator_id/obs_id>obs_id <ivo://creator_id/obs_id> (slash separator)
> -> the regular IVOID/./

No, that's not the case.  The creator DID is completely unrelated to
the discovery or even the publication of the dataset itself --
publication is a publisher's job, and they can issue their own DIDs.
Let me make a very concrete proposal for how I think this could
easily work, choosing the case of VizieR:

(1) you register an vr:Organization record for VizieR once,
ivo://cds/vizier, say.  (you should do that anyway, I've already sent
a mail to Sebastien after I found out there is no such record so far)

(2) each HiPS' creator DID is just that ivoid with a local part of
the table name, for instance, 

  ivo://cds/vizier?J/ApJ/476/311/table4

(perhaps, depending on your local conventions, it might be wiser to
make clear that this is a hips and use

  ivo://cds/vizier?hips/J/ApJ/476/311/table4

or even

  ivo://cds/vizier?J/ApJ/476/311/table4&format=hips

-- but that's up to the creator, as it should be; the only thing
that needs to be made sure that you'll never hand out the same
identifier for two different things).

(3) the registry record 

ivo://CDS.VizieR/J/ApJ/476/311

would remain as it is, except it'd have one or more new
capability/ies as described in my last mail.  There's no problem in
the two identifiers being different, just as there's no problem that
a car's license plate number is different from its chassis number.

*If* you find out that discovery by creator DID becomes important
*using the Registry* (e.g., to find the nearest mirror or similar),
you could create an extension type for vr:Capability that contains
that information, but I'd first wait if there's actual demand for
such a functionality.  If you see there is, it's not hard to retrofit
it.

> 3) to declare their HiPS node (= HiPS server). In this case I understand
> that the IVOIDs would beivo://creator_id <ivo://creator_id?obs_id>?
> <ivo://creator_id?obs_id>obs_id <ivo://creator_id?obs_id> (question mark
> separator) -> the new IVOID scheme /(//The way that these IVOIDs will be
> determined is still a little bit obscure for me and I still believe that
> there is a confusion between publisher and creator. Also I'm pretty sure
> that we will have potentially various IVOID syntaxes for the same resource
> [cf (1)])

Again, no.  A HiPS node can assign *publisher* DIDs as it sees fit
(it plays the role of the registry of motor vehicles in that case).
But there's no reason for the HiPS standard to worry about that.  The
DAL protocols say all that needs to be said on that.

You are concerned (again, apologies for noticing this too late) with
creator DIDs.  Therefore, a HiPS standard might rightfully worry
about making the *creator* DIDs (the chassis numbers) searchable.
You could, for instance, say that a SIA service serving HiPSes must
support a CREATORDID parameter (as in sect. 4.1.2.13 of SSA 1.1).

But that, again, is essentially down to the use cases -- I'd always
start from there.

Cheers,

          Markus