Identifier issues
Ray Plante
rplante at poplar.ncsa.uiuc.edu
Fri Sep 12 10:45:34 PDT 2003
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