IVO ids and Data Sets Identifiers
Tony Linde
ael at star.le.ac.uk
Wed Sep 24 09:42:20 PDT 2003
> If there is a need to define an authority as overarching
> several registered resources, there is in principle no reason
> to require that such linking be visible in the identifiers -
> especially not if it means a loss of convenience in common
> situations. What counts in the identifier is the registered
> resource that it points to.
I would have thought the 'common' situation was where an organisation wanted
to register resources (data sources, services) under an authority id which
it owned and controlled.
If the publications really cannot live with the IVOA resource identifier
then they can come up with their own naming scheme and then, using some
service, map to the relevant VO resources.
Cheers,
Tony.
> -----Original Message-----
> From: Arnold Rots [mailto:arots at head-cfa.harvard.edu]
> Sent: 24 September 2003 16:04
> To: Tony Linde
> Cc: 'Francois Ochsenbein'; registry at ivoa.net
> Subject: Re: IVO ids and Data Sets Identifiers
>
>
> I'm all in favor of getting something done, but we're not
> experimenting here - at least not where it concerns the
> identifiers used for the the literature links.
>
> In abstracto you are right. But I agree with Francois that
> we ought to make the conversion easy for what I expect to be
> a common case - where an authority ID translates into a root URL.
>
> I may be dense, but what is the advantage of having multiple
> resources registered under the same authority - other than
> abstract elegance?
>
> If there is a need to define an authority as overarching
> several registered resources, there is in principle no reason
> to require that such linking be visible in the identifiers -
> especially not if it means a loss of convenience in common
> situations. What counts in the identifier is the registered
> resource that it points to.
>
> - Arnold
>
> Tony Linde wrote:
> > > My only problem is that the usage of the # will forbid the
> > > usage of the same identifier as an IVO identifier AND as an
> > > UR[IL] directly usable to point to a dataset from an
> >
> > Good. It should not be usable as a url. It's sole purpose is as an
> > identifier of a resource within the registry and it has no meaning
> > other than that.
> >
> > > I feel it's a pity to introduce this incompatiblity -- and
> > > moreover I agree fully with Arnold, I cannot understand the
> > > necessity of a resource_key. What you need is just a unique
> > > identifier, which will be supplied by the Authority.ID . It's
> > > not the role of the registry to define this, IMHO.
> >
> > The registry won't be defining either. Users of a registry will be
> > able to register an authority id and then define the resource keys
> > under that authority. The registry will ensure that the
> resource key
> > chosen is unique within that authority.
> >
> > This has been discussed for months now. The telecon
> yesterday agreed
> > that the resource identifier WD should be submitted as a Proposed
> > Recommendation to allow projects to try it out, especially
> during the
> > Jan demo.
> >
> > If it turns out that people are only registering one resource under
> > each authority then we can revisit the situation. Let's get
> something
> > *done*.
> >
> > Cheers,
> > Tony.
> >
> > > -----Original Message-----
> > > From: owner-registry at eso.org [mailto:owner-registry at eso.org]
> > > On Behalf Of Francois Ochsenbein
> > > Sent: 24 September 2003 15:22
> > > To: registry at ivoa.net
> > > Subject: Re: IVO ids and Data Sets Identifiers
> > >
> > >
> > >
> > > Tony,
> > >
> > > My only problem is that the usage of the # will forbid the
> > > usage of the same identifier as an IVO identifier AND as an
> > > UR[IL] directly usable to point to a dataset from an
> > > electronic article. It therefore
> > > means that the 2 things have to be disjoined because it is
> > > not possible (in the HTTP sense) to make a distinction between
> > > //Authority.ID/(resource_key)#(dataset_1) and
> > > //Authority.ID/(resource_key)#(dataset_2)
> > >
> > > I feel it's a pity to introduce this incompatiblity -- and
> > > moreover I agree fully with Arnold, I cannot understand the
> > > necessity of a resource_key. What you need is just a unique
> > > identifier, which will be supplied by the Authority.ID . It's
> > > not the role of the registry to define this, IMHO.
> > >
> > > Cheers, francois
> > >
> > > >This is in reply to both Francois and Arnold.
> > > >
> > > >An AuthorityID is not a service and so will not have an
> > > invocation URL
> > > >associated with it. The AuthorityID is simply a way of grouping
> > > >resources and allowing a registry to know that when it assigns a
> > > >ResourceKey, it is globally unique (since no other registry
> > > can assign
> > > >a ResourceKey to that AuthorityID).
> > > >
> > > >So a service *must* have a ResourceKey as part of its unique
> > > >identifier, as well as the AuthorityID.
> > > >
> > > >On the issue of the dataset identifier, there is no problem with:
> > > > ivo://Authority.ID/(resource_key)#(dataset_identification)
> > > >since this is not being sent to an http server. It will be
> > > interpreted
> > > >by some piece of software (which can interpret the
> ivo:// protocol)
> > > >which will understand that everything before the '#' sign is
> > > a resource
> > > >identifier and everything after it a dataset identifier. The
> > > software
> > > >will use the resource identifier to look up the service
> > > metadata, get
> > > >the service invocation method (web service or cgi or
> > > whatever) and then
> > > >call that service using the dataset identifier (as a
> > > parameter to the
> > > >web service or as the value part of a cgi '?name=value' pair).
> > > >
> > > >The ivo:// protocol is for the use of *VO software* only and
> > > not http
> > > >servers. They may use the same URI convention but they are
> > > completely
> > > >separate and different naming conventions.
> > > >
> > > >Cheers,
> > > >Tony.
> > > >
> > > >> From: owner-registry at eso.org
> [mailto:owner-registry at eso.org] On
> > > >> Behalf Of Francois Ochsenbein
> > > >> Sent: 23 September 2003 22:34
> > > >> To: registry at ivoa.net
> > > >> Subject: IVO ids and Data Sets Identifiers
> > > >>
> > > >>
> > > >> If I may intervene on this subject of the IVO identifiers, I
> > > >> would strongly suggest not to use the hash symbol as a
> delimiter,
> > > >> because it has a special meaning in the HTTP
> > > >> protocol: it indicates a marker in the document, and what
> > > >> comes after the # symbol is quite generally ignored by the
> > > >> HTTP servers. For instance the output of an HTTP GET to
> > > >>
> http://www.stsci.edu/ftp/science/hdfsouth/warnings.html#NICMOS
> > > >> is exactly identical to the output of
> > > >> http://www.stsci.edu/ftp/science/hdfsouth/warnings.html
> > > >> (the browser simply scrolls the document to position it at
> > > >> the "NICMOS" marker)
> > > >>
> > > >> Therefore in the general scheme of the IVO identification
> > > >>
> > > >>
> ivo://Authority.ID/(resource_key)(dataset/subset_identification)
> > > >> the # sign could maybe appear in the 3rd part
> > > >> (dataset/subset_identification) but certainly not a separator
> > > >> between the parts 2 and 3 (and moreover not between the parts
> > > >> 1 and 2) if it is wished that a resource can be reached using
> > > >> the http conventions.
> > > >>
> > > >> In fact, for datasets I would more agree with Guenther's
> > > >> arguments: one Authority.ID, and what follows it is defined
> > > >> under the responsability of the Authority.ID who "publishes"
> > > >> the way to access to the data. The dataset can effectively be
> > > >> a simple document like
> > > >>
> > > ivo://Authority.ID/Resource-Service/Repository/Intrument/datasetID
> > > >>
> > > >> but could also be something like
> > > >>
> > > >>
> > >
> ivo://Authority.ID/RepositoryQuery?instrument=Intrument&ID=datasetID
> > > >>
> > > >> As long as there is no ambiguity (the Authority.ID may
> "delegate"
> > > >> the "naming space" to different missions or instruments or
> > > >> whatever) the role of the identifiers is fulfilled.
> The problem
> > > >> with the links from the journals is, as pointed out by
> Bob, the
> > > >> requirement for long-term persistence which can only
> be achieved
> > > >> if any change in the curator is
> > > >> propagated to the Registry who has to make this mapping
> > > between the
> > > >> 'permanent' and the 'actual' identifiers (the GLU was not bad
> > > >> in this role!)
> > >
> > > ==============================================================
> > > ==================
> > > Francois Ochsenbein ------ Observatoire
> > > Astronomique de Strasbourg
> > > 11, rue de l'Universite F-67000 STRASBOURG Phone:
> > > +33-(0)390 24 24 29
> > > Email: francois at astro.u-strasbg.fr (France) Fax:
> > > +33-(0)390 24 24 32
> > > ==============================================================
> > > ==================
> > >
> >
> --------------------------------------------------------------
> ------------
> Arnold H. Rots Chandra X-ray
> Science Center
> Smithsonian Astrophysical Observatory tel: +1
> 617 496 7701
> 60 Garden Street, MS 67 fax: +1
> 617 495 7356
> Cambridge, MA 02138
> arots at head-cfa.harvard.edu
> USA
> http://hea-www.harvard.edu/~arots/
>
> --------------------------------------------------------------
> ------------
>
More information about the registry
mailing list