Identifiers 2.0 new internal WD

[Pierre Fernique]

Hi Markus and other registry members,

My comments to the last WD.
In resume, I totally agree Markus's proposal to resuse official URI RFC 
definition for our IVORN specification. This normalisation effort 
totally follows our own CDS reflexion about CDS resource homogeneous 
identification in the framework of a MOC server prototype (VizieR 
tables, Aladin surveys (HiPS), and Simbad => 
http://alasky.unistra.fr/MocServer/query?ivorn=*). I was just a little 
bit surprise about the usage of # proposed in the last point.

Many thanks Markus,
Pierre Fernique

------------

Here the details of my comments on the last WD. => 
http://docs.g-vo.org/Identifiers.pdf (IVOA Identifiers - Version 2.0 - 
IVOA Working Draft 2014-08-20)

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.

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.

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

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

Le 29/04/2015 15:20, Markus Demleitner a écrit :
> Dear Registry WG,
>
> On Tue, Jan 27, 2015 at 03:34:16PM +0100, Markus Demleitner wrote:
>> Frankly, I'm not quite sure why we should go into the trouble of
>> overriding all the perfectly good BNF from RFC 3986.  Sure, we should
>> put some restrictions (nothing funny in the authorities, no queries
>> and fragments in whatever you resolve in a registry,...), but I'd
>> think we should say "IVORNs are run-of-the-mill RFC 3986-type URIs,
>> *except* (a), (b), and (c)" rather than trying to pretend Identifiers
>> could possibly work without RFC 3986.
>>
>> Now, that would finally be a complete rewrite of the document, and
>> before I even embark on the journey there:
> Because nobody protested back in winter, I've gone ahead and followed
> that program in volute revisions 2920 (sorry for the sheer size of
> the diff) and 2926.  For a formatted PDF, head to
>
> http://docs.g-vo.org/Identifiers.pdf
>
> Despite the massive changes, the specification content has not
> changed much.  To get a quick idea of what this is about, please have
> a look at section 1.3 ("Rationale for Version 2") and the entire
> section 4 (and I'd really appreciate if you could find that time for
> that).
>
> Also, since that section 2 is almost all-new, I would be especially
> grateful if standards lawyers could have a closer look at that (I'm
> trying hard to not stare towards Glasgow too obtrusively now).
>
> If you won't find time to do that within, say, two weeks, please let
> me know -- otherwise I'd submit that as a WD after another round of
> proof-reading by mid-May so there's some time for the rest of the
> IVOA to have a look at it before Sesto.
>
> Again, feel free to commit contributions of all sorts directly to
> volute -- that's what version control is for.
>
>
> Until then, I'd have another look at the Registry Interfaces revision
> (mentioning RofR, in particular); incidentally, I'm planning to
> downgrade that to a minor version (i.e., 1.1), as now that RegTAP is
> no longer a part of it we're not formally breaking anything major as
> far as I can see.  Objections and contributions are welcome here,
> too, at any time.
>
> Thanks,
>
>          Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20150512/51ad2444/attachment.html>