Identifier issues
Tony Linde
ael at star.le.ac.uk
Fri Sep 12 10:59:22 PDT 2003
Hi Ray,
Does my response to Arnold's email solve these?
Cheers,
Tony.
> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org]
> On Behalf Of Ray Plante
> Sent: 12 September 2003 18:46
> To: registry at ivoa.net
> Subject: Identifier issues
>
>
> Hi all,
>
> Now that we're on the registry list, let me attempt to define the
> discussion a little bit. There are two issues being
> discussed that have
> ramifications for the Identifier WD. (I'm sure I'm partly
> responsible for
> mixing these two.)
>
> 1. Can an IVOA identifier exist for a resource that is not
> registered
> anywhere? If so, what are the constraints (i.e. "as
> long as ...")?
>
> Doug has described a desire to tag datasets as
> resources with VO
> metadata, including a global identifier, even if that
> dataset is not
> (yet or ever) registered in an IVOA registry. Such a
> dataset and
> its metadata may be exposed to users through a service
> that is not
> strictly a registry.
>
> 2. The ADEC consortium is working on a scheme for identifiers
> that journals can be used to refer to datasets that
> results were
> derived from. For a more detailed explanation of its
> requirements,
> I direct you to an included email below from Arnold
> Rots, who is
> working with ADEC on this. Can we ADEC and IVOA
> identifiers be made
> compatible in some way?
>
> Here are the essential differences (I think):
> an ADEC identifier...
> * refers to a dataset in some sense.
> * can be resolved to a way to get the dataset.
> * is persistant: it will always refer to the same dataset.
> * is location-independent: if the dataset moves (e.g. is
> accessed through a new interface, URL, etc.), the
> resolution is updated. It can be resolved to multiple
> locations (yes?).
>
> an IVOA identifier (as currently defined)...
> * refers to any kind of resource, which could
> include a dataset.
> * can be resolved to a description of the resource,
> which can
> include a way to access it. Note, however, that we
> currently view datasets as too fine-grained a resource
> for our registries (which handle the resolving).
> * is not necessarily persistant (though this could
> be changed).
> * is organization-dependent, and thus, to some extent
> location-dependent.
>
> Are there answers to the above questions?
>
> cheers,
> Ray
>
> ---------- Forwarded message ----------
> Date: Wed, 10 Sep 2003 16:47:51 -0400 (EDT)
> From: Arnold Rots <arots at head-cfa.cfa.harvard.edu>
> To: Tony Linde <ael at star.le.ac.uk>
> Cc: Arnold Rots <arots at head-cfa.cfa.harvard.edu>,
> Ray Plante <rplante at poplar.ncsa.uiuc.edu>, registry at ivoa.net
> Subject: Re: IVOA Identifiers Working Draft
>
> 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/
>
> --------------------------------------------------------------
> ------------
>
More information about the registry
mailing list