Al:
One of the goals of the Storage Resource Broker implementation is to
separate the persistent name of an object from its storage location and
from its access protocol. This is possible if the object is a member of a
collection that manages the "pattern of traits" or attributes associated
with the object. The trade-off is that access to data sets is now done
through the collection, and the traditional Dublin Core attributes must be
augmented with information about the storage location of the object.
The SRB can be thought of as a URN management mechanism for associating the
storage location of an object with collection maintained identifiers. If a
consensus is reached on global names, the new identifier can be added to
the collection attributes.
There are many advantages to this approach. It is easy to manage
replicates of the data set, it becomes possible to aggregate data sets into
containers for storage in archives, it becomes possible to automate
migration of data sets across evolving software and hardware systems, it
makes it feasible to put distributed data sets under collection control.
Using a universal name that also serves as an access mechanism that
incorporates the location and protocol makes it very difficult to do any of
the above tasks.
Reagan Moore
>The Storage Resource Broker project at SDSC eventually abandoned the idea
>of an identifier (i.e. a one-trait sufficient key) as persistent
>identification for objects, and operates on the basis of a tuple or pattern
>of traits as a sufficient-for-identification key. This may be the general
>answer in the large. Identifiers are shortcuts and they usually work; to
>be sure, refine the identification expression [a.k.a. query] until a unique
>referent is returned.
Reagan Moore