IDs and ID services
Ray Plante
rplante at poplar.ncsa.uiuc.edu
Mon Feb 3 12:37:24 PST 2003
I'm happy to see the international discussion picking up. This message is
mainly about identifiers; however, I wanted to preface it with some
context about the discussion initiated within the NVO Metadata Working
Group. While registries and the use of IDs are interdependent, I have
been trying to talk about them separately as we define the scope of the
problem we want to address (and hopefully bring some order to what
otherwise might be a random walk).
On the ID side, I assembled some requirements for IDs from the many
comments from the discussion
(http://rai.ncsa.uiuc.edu/~rplante/VO/metadata/oidreq.txt). This
should looked at like a menu--pick the things you agree with. Better yet:
indicate the things you don't agree with. Requirements are generally
considered a good first step to design as it defines the scope of the
problem you are trying to solve. As Andy implied, the requirements for
IVOA as a whole might be looser that what we specify for NVO.
This week, Tom shared should thoughtful comments about how we might
approach IDs. (He brought up the term "keys", by analogy to DBs; however,
the term is synonymous.) This message is an attempt to enunciate how his
framework maps onto the requirements list--I hope Tom can comment on
whether I got it right. The main conclusion is that IDs are only used
determine "sameness"; infering ownership or derivation directly from IDs
is not to be required.
1. Single Framework: Okay
2. Determine "sameness" from 2 IDs: Okay for the most part
* direct determination only possible when IDs have been issued by
the same ID service.
* cross-ID service comparison requires translation.
* because data mirrors can reuse identifiers (req. 7), it is
expected that the need for translation will be rare and
practically unnecessary.
3. Avoiding needless duplication: Okay (see notes above).
4. Identifying different formats of same object: Unspecified (No?)
5. Identifying curator: No
* The ID is not necessarily issued by the curator. However,
it is possible to retrieve this information by using the ID
to access the item's description.
This might suggest a different requirement (which I've added):
5.b. It should be easy to identify the resource having issued the
identifier.
This would allow one to get more information about the item
identified. Note, however, that Tom's outline does not imply
this requirement (since one must query an ID service to determine
if it includes a particular ID).
Another requirement I might add which was part of the registry
requirements:
5.c It should be possible to use the ID to access a unique
description of the item it identifies.
That is, for any information you can't glean from an ID, you can
get from a description accessed with the ID.
6. Collection membership: No
7. Reuse of IDs by mirrors: Yes
8. Derivation: No
9. Provider control over assignment: Yes
* Provider can run their own ID service.
Personally, I think this approach is about right in its scope.
However, I think it would be useful if all you had was an ID, you
could infer which service you could invoke to get more information
about it. As an example, if you have an ID, "//cas.le.ac.uk/TonyLinde",
you could go to "http://cas.le.ac.uk/getDescription?//cas.le.ac.uk/TonyLinde"
and discover what this TonyLinde is and who takes care of it. I also
think that we need to decide whether (for example) the same images in
different formats (e.g. as returned from an SIA image query) should have
the same ID.
cheers,
Ray
More information about the registry
mailing list