Identifiers 2.0 new internal WD

[Markus Demleitner]

Dear Pierre, Dear Registry WG,

On Tue, May 12, 2015 at 12:05:24PM +0200, Pierre Fernique wrote:
> My comments to the last WD.

Thanks for reviewing the document.

> page 10 - "/Applications are encouraged to present authority identifiers
> using all lower-case characters./"
> => Very often, organization names are acronyms. In this case, the uppercase
> notation is not only more logic, but sometime required by the institute
> internal policy (CDS, NED, ...) - I'm not sure that we can keep this
> sentence.

Firstly, that's not new text, it's been kept from version 1.0.

Now, since it's just a recommendation and has no functional
consequences I can see, I wouldn't mind striking it -- but since this
is not my text and I'm not sure what the rationale for putting it in
was I'd like to give everyone the chance to protest.  If nobody
speaks up, I'll strike that clause.

> page 12 - 2.5 "/IVORNs can always be resolved to a Registry record by
> querying a search-//able registry/" and "/If an IVORN does not resolve in
> the Registry, clients SHOULD assume it//is obsolete and that any IVOID built
> with it does not reference an existing//resource or entity, either./"
> => One consequence will be the registration of all individual VizieR tables
> (~15.0000) in the VO Registry (only catalogs are presently registered). It
> is a good evolution in the sens that the catalog level in the registry has
> been always an issue for application (server side and client side) which
> have to querying and manipulating tables, and not catalogs.

These constraints are also (essentially) taken over from version 1,
so just for the record I'd maintain that nothing changes in that
respect.

Registering tables, of course, is a very worthwhile thing anyway, and
I'll have some things to say about that in Sesto.

> page 15 - Dataset Identifiers
> A little bit difficult to understand this section because it is very DAL
> specific. An example would be probably welcome.
> Maybe, we could precise that the level of granularity of resources
> registered in the Registry depends of the provider policy. For instance, CDS
> will not use fragment identifier for distinguishing bands of a survey, or

As you shouldn't unless the various bands were all in one document.

> tables of a catalog, because we record them individually. So we have:
> ex: ivo://CDS/P/2MASS/J instead of  ivo://CDS/P/2MASS?J,
> ivo://CDS/I/213/table3 instead of  ivo://CDS/I/213?table3

Since, as you say, the demarcation between "VO resource" and
"dataset" is up to the data provider, it'd be perfectly all right to
do this.

But this point goes a bit deeper since with it we're also in
VODataService's realm.  So, in ivo://CDS/P/2MASS's Registry record
there would be a tableSet consisting of J, H, and K_s table elements,
say.

And that now gets me thinking, as each of these table elements might
be referenced as table *metadata* using a fragment identifier into
the Registry record (at least it would be straightforward to define).
The *data*, on the other hand, definitely calls for a query part.

However, I'd say these are largely topics for a revision of SCS, and
there we'll need to figure out what we really want to reference; I'd
be happy if we could keep these questions out of Identifiers, except
of course we need to make sure that we don't needlessly constrain
what SCS-Next might be doing.

> page 16 - Standard Identifiers
> The # usage for expressing level of compliance (minor, major version number,
> model version...) seems to me a surprising extension of IVOID usage, and may
> be a little bit too specific to Markus RegTAP implementation. In fact, this
> idea merges ID syntax and query language facility. I would prefer to
> separate these two goals:
> /standard_id LIKE ???ivo://ivoa.net/std/exampleProto#query-1.%???/
> =>
> /standard_id LIKE ???ivo://ivoa.net/std/exampleProto' WHERE query...//
> /

Just to remind everyone how this developed -- the initial problem
came up at

http://mail.ivoa.net/pipermail/registry/2014-February/004909.html

and the solution proposed here then was more or less arrived at 
in Madrid.

In principle I agree that separating "capability" and "version" with
actual syntax (rather than informal structure of StandardKeys) might
be preferable.  But that would mean new Registry records for every
version of a standard, which wasn't very popular, and also would go
against the spirit of StandardsRegExt.

If one keeps multiple versions of a standard in a single
StandardsRegExt record, I believe there's little alternative to the
proposed scheme if you want the full IVOIDs to refer to something.

Now, Aladin clearly is a major (potential) consumer of this kind of
information ("give me all image services I can talk to"), so
reservations you guys have are clearly relevant.  Could perhaps try
again to explain where you see problems with what Identifiers
proposes and what you think it should do instead?

Thanks,

           Markus