Page History
Proposed URI Mapping for DSpace Object Model
This page proposes a mapping of objects in the DSpace data model
(aka Object Model) onto Uniform Resource Identifiers (URIs).
The URI scheme was developed specifically for the History system prototype
but it may also find uses in the AIP prototype implementation
and policy expression languages – and in any application that needs a stable,
persistent, URI naming an object in the DSpace object model.
Objectives
The specific goals of this proposal are:
- Conform to existing, applicable standards.
- URIs are meaningful and human-readable.
- Every URI has a one-to-one correspondence with its Object: there is only one valid URI for any given object.
- The URI is resolvable to an object within its realm of uniqueness:
- URIs of persistent objects such as Items and Collections are unique and resolvable globally.
- URIs of archive-dependent objects (such as a Bitstream's asset-store location) are only resolvable within the archive.
- Follow the RDF convention of a common URI prefix with identifying elements in the URI "fragment", so RDF viewers display it correctly in condensed form.
Design Choices
We propose to base DSpace Object Model URIs on the
Info URI Scheme.
If this proposal is adopted, we will request to
register the
Code Block |
---|
"dspace" |
namespace in the
Code Block |
---|
info: |
scheme.
Why Not URLs?
Why not use URLs in e.g. the
Code Block |
---|
http: |
or
Code Block |
---|
ftp: |
scheme?
Recall that it is a goal for the URIs to correspond 1:1 with objects, and
objects may be duplicated (replicated or custody-transferred) at
other archives, so they would then have multiple URLs.
Also, any identifier based on the domain name of a network host
is not going to be persistent.
Besides, the URI does not have to be globally resolvable. It only has to be
resolvable in the context where the object is available, e.g. within
a DSpace archive that contains the Item.
URI Specification
The general formats for a DSpace URI starts with
the scheme
Code Block |
---|
info: |
and the namespace
Code Block |
---|
dspace |
, followed by
a path element delimiter *
Code Block |
---|
"/" |
* (slash). The rest of
the URI depends on the object to be described. We have established rules
for two classes of objects:
1. First-Class DSpace Objects with Persistent Identifiers
Any "first-class" object with a persistent identifer – i.e. a Handle – can
be mapped to a URI based on that Handle, following the pattern:
Panel | ||||
---|---|---|---|---|
handle
subfragment |
For example, any DSpace Item, Collection, Community, and Site has a globally
unique Handle. An Item with the Handle
Code Block |
---|
1721.1/4325 |
would have this URI:
Panel |
---|
info:dspace/handle#1721.1/4325 |
The subfragment notation is used for the "persistent" identifiers of
Bitstreams. A Bitstream in the preceding example's Item with the
Sequence ID 3 would be identified by this URI:
Panel |
---|
info:dspace/handle#1721.1/4325:3 |
NOTE: The "handle" word in the URI path is there to declare that the unique
identifier following is a CNRI Handle. Since DSpace may eventually
implement other persistent identifier schemes, they would each be mapped to
a class of DSpace URI with the name of the type of PID in place of "handle".
2. Representing Internal Objects
Some applications need to refer to objects within the archive with a
URI, e.g. because it is needed within an XML or RDF representation and a URL is
inappropriate. The first such case is in the internal AIP METS document,
which needs to identify a file in the Asset Store, bypassing the object model.
The solution is to add a different unique keyword to the DSpace URI prefix
and let the application dictate the rest of the URI. In this case,
we give it the keyword
Code Block |
---|
asset |
, and the format (for file-based
local asset stores, at least) is a path element naming the bit-store type
and an identifying path in the fragment. The general format for a local file is:
Panel | ||
---|---|---|
storagetype#assetstore:assetpath |
and for a registered asset it's:
Panel | ||
---|---|---|
storageType#assetStore:assetIdentifer |
In each of the above formats:
- storageType is either
orCode Block file
, depending on whether local file storage or the SRB is used.Code Block srb
- assetStore is the asset-store prefix under which this file is stored; there can be several configured. In the
case it would be a localCode Block file
URI.Code Block file:
- assetIdentifier is the identifer, unique only within that asset store, of the file.
Here is an example: The URI
Panel |
---|
info:/dspace/asset/file#file%3A%2Fvar%2Flocal%2Fdspace%2Fassetstore%2F:47662570435556328444977060694430104239 |
is broken down into:
Panel |
---|
info:/dspace/asset -- actual asset in the bitstore (as opposed to "registered"). |
Note how only one URI can be derived from the asset file, and likewise the
URI corresponds directly to exactly one file. Given the asset store prefix
and filename it is completely straightforward to match that to a Bitstream
object.
API
The following methods are implemented in patches to DSpace version 1.4.1.
Note that there is only a method to obtain the Handle-based persistent URI
of any archival object; there is no corresponding method to resolve it,
because none of the code needed it. The implementation is quite
straightforward, however.
Panel |
---|
// in RDFRepository
// in Bitstream
// in Bitstream
|