IVOA Identifiers Working Draft

[Arnold Rots]

Tony,

Maybe the best thing is indeed an example to explain how it's being
used.  Simply, the requirement is that such an identifier can be
inserted in a paper and allow the readers in perpetuity to find the
observation dataset that was being used for that paper.  So, the
identifier represents the result of a query (or, if you prefer, you
can consider it a complete query in its own right) and it is not
necessary that it points directly to the bits, but allows the user to
find (and retrieve if public) such a dataset.

If you used Chandra observations 2000 and 2900 in your paper, you
would include identifiers Sa.CXO/2000 and Sa.CXO/2900
The client that uses these identifiers (the ADS) would then 1) verify
that these identifiers are valid and 2) harvest the URLs where the
(pointers to the) datasets can be found.

Currently, those would be:

http://cda.harvard.edu:9011/chaser/ocatList.do?obsid=2000
http://cda.harvard.edu:9011/chaser/ocatList.do?obsid=2900

If the CXO archive would move to some other location, these URLs would
change but the identifier should remain valid.  I.e., Sa.CXO will be
found at another physical resource (and the registry had better be
aware where it can be found), but that new physical resource would be
required to support all resource keys that were previously defined by
the previous owner of the naming authority Sa.CXO.

All the metadata on observations 2000 and 2900 can be retrieved from
the Chandra observation catalog, but I see no reason why all that
information should be stored at the top-level registries as well.  Or,
alternatively, the registry might know how to query for those metadata.

Hope this helps,

  - Arnold

Tony Linde wrote:
> Hi Arnold,
> 
> > I come back to the compatibility with persistent identifiers for
> > literature linking and argue against making resource keys mandatory.
> 
> I don't see how the two are incompatible. It is the *combination* of
> AuthorityID and ResourceKey which identifies a resource and there is
> nothing to stop this being persistent.
> 
> > The registry should only have the naming authority an be able to
> > translate that into a root URL, at which point any valid resource key
> > can be appended. 
> 
> I certainly don't agree that a ResourceKey is constructed at the point of
> a query if that is what you are saying. How can you save the structure of
> a workflow if none of the resources referred to have persistent
> identifiers. It also means that no-one can save the identifiers for
> favourite resources in order to reuse them. Come to think of it, if you
> don't store metadata for resources, how do you answer any queries on the
> registry?
> 
> Maybe we just understand the term 'resource' to mean different things.
> What do you mean by it? Can you give some examples?
> 
> Cheers,
> Tony.
> 
> 
> On Wed, 10 Sep 2003 15:22:24 -0400 (EDT), "Arnold Rots"
> <arots at head-cfa.cfa.harvard.edu> said:
> > I come back to the compatibility with persistent identifiers for
> > literature linking and argue against making resource keys mandatory.
> > The registry should only have the naming authority an be able to
> > translate that into a root URL, at which point any valid resource key
> > can be appended.  It would be foolish to insist that all resource keys
> > at this level of granularity be contained in the registry.
> > 
> >   - Arnold
> > 
> > Ray Plante wrote:
> > > Hi Tony,
> > > 
> > > On Wed, 10 Sep 2003, Tony Linde wrote:
> > > > A few comments on this wrt the sample registry based on the new schema
> > > > (adil-v0.8.1.xml).
> > > > 
> > > > Neither resource in the sample (one Organisation and one DataCollection) has
> > > > a ResourceKey within their identifiers. I think ResourceKey should be
> > > > mandatory in all resources except one which we should create for, say,
> > > > Authority: this could hold any info about the authority including a pointer
> > > > to an organisation.
> > > 
> > > I went back and forth on this one.  (What I really needed was a second 
> > > opinion.)  I'll change this.
> > > 
> > > > The document also suggests that only people from a 'naming authority' can
> > > > add resources to a registry. In my mind, a registry should have a default
> > > > AuthorityID so that anyone could add a resource to it whether they are from
> > > > a recognised naming authority or not.
> > > > 
> > > > A registry could be set up to refuse registrations from non-authority
> > > > personnel but this should not be the default, I think.
> > > 
> > > Agreed.  I'll put a clarify remark in the WD.  
> > > 
> > > cheers,
> > > Ray
> > > 
> > > 
> > --------------------------------------------------------------------------
> > 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/
> > --------------------------------------------------------------------------
> > 
> __
> Tony Linde                       Phone:  +44 (0)116 223 1292
> AstroGrid Project Manager        Fax:    +44 (0)116 252 3311
> Dept of Physics & Astronomy      Mobile: +44 (0)7753 603356
> University of Leicester          Email:  ael at star.le.ac.uk
> Leicester, UK   LE1 7RH          Web:    http://www.astrogrid.org
> 
--------------------------------------------------------------------------
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/
--------------------------------------------------------------------------