W3C home > Mailing lists > Public > uri@w3.org > May 2000

Re: [Fwd: Re: Approval of initial Dublin Core Interoperabiity Qualifiers]

From: by way of <moore@sdsc.edu>
Date: Tue, 09 May 2000 00:37:26 +0900
Message-Id: <>
To: uri@w3.org
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
Received on Monday, 8 May 2000 14:05:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:01 UTC