Resource identifiers

[Tony Linde]

I'd like to add my own view of the debate going on in the NVO metadata list
about identifiers but have posted it here for the attention of the wider
audience.

A. the ResourceId is a globally unique identifer for any resource recognised
and used by VO systems.

B. this identifier has two components, an AuthorityId and a ResourceKey,
both of which are constructed according to set rules (see Ray's previous
email) and both of which (and therefore the ResourceId itself) are
*meaningless*, even though they look like components of a URL.

C. a Registry will store metadata associated with resources. These metadata
are replicated between registries according to some protocol yet tbd. A
registry can choose what types of resources it lists but it will always be
up to date as of its last harvesting round (presumably daily/nightly in most
cases).

D. an AuthorityId can only be used in constructing a ResourceId by one
registry (the protocol for ensuring this is yet tbd). A registry can 'own'
many such AuthorityIds. The registry will operate its own rules about who
can register resources under any given AuthorityId.

E. a registry is also a resource with its own ResourceId. As such its
metadata, which will include the list of AuthorityIds it 'owns' and a URL
for invoking it, will be replicated. The schema for a Registry type resource
needs to be added to the new 0.8.1 schema. Registry-type resources should be
replicated around ALL searchable registries.

F. to find out anything about any resource it is simply a matter of querying
any searchable registry and supplying the ResourceId. If that registry does
not replicate that metadata, it can either query any full registry (one
which replicates all resource metadata) or look up the resource metadata for
the originating registry (by searching on the AuthorityId component) and
querying that.

G. a resource should only be registered with one registry. If it is
registered with more than one then each entry will be seen as referring to a
different resource.

H. any relationship between resources will be detailed in the resource
metadata. My preference is for a (0-many) Relationship complex type as part
of every resource metadata which includes a relationship type and the
identifier of the related resource.

(NOTE: wrt mirrors, the metadata of the base dataset might be stored as a
DataCollection resource and the services which provide access to that data
could be registered as SkyService (or SkyNode) resources with relationships
to the DataCollection of 'PrimaryAccess', 'MirrorService' etc.)


This, as I say, is how I see the registry, resource and identifier issues
and is the basis of my inputs to the identifer document and the new schemas.
I think I've addressed most of the issues raised in the metadata thread
without directly answering any of the dozen or so emails. I hope the authors
of those emails, if they disagree with my analysis, will reply in this list.


Cheers,
Tony. 

__
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