It can be accesed like this:
The PURL Resolver can perform much more complex substitutions than the basic OCLC PURL Server:
- Purl references to objects will be decomposed, and a set of redirects appropriate to the collection will be selected.
- Different redirects may be selected based on the content model of the Fedora object, and whether a datastream or object-level rendering is requested.
- The object's PID, shortItemID, or fullItemID may be substituted anywhere within the redirected URL.
- The resolver breaks the PURL into pieces (collectionID, formatID, etc.).
- The pieces are used to construct a fullItemID.
- The SRU Server is searched with the fullItemID to retrieve the Fedora pid and content model. If the primary SRU server does not contain the object, alternate SRU servers will be searched.
- Settings in the configuration file are used to build an appropriate redirect URL based the content model, collectionID, and formatID.
- Control is redirected to the redirect URL.
Configuration of the PURL Resolver
The PURL Resolver configuration file (purlResolver.conf) contains three major sections. The first section contains basic resource locations, like the URLs for SRU servers.
The second section contains mappings between formatIDs and Fedora datastream names. For example:
The main property name "pageScreen" is simply used to tie the two statements together; it has no other use, and could easily be "foo". These statements indicate that when a formatID of "page/screen" is found in the PURL, the resultant redirect will be to the "SCREEN" datastream in the appropriate Fedora object.
No other configuration is needed for datastream-level PURLs. Any recognized collection (see below) will use the same datastream mappings.
The following formatIDs are being used:
Collection-specific redirect mappings
The third major section of the configuration file contains detailed redirect URLs for objects in each type of recognized collection. Let's start with a simple example:
As with the formatID mappings, the main property name "slocum" only serves to tie the statements together. As long as it is unique within the configuration file, it can be any name. This set of statements specifies that "lilly/slocum" is a valid collection (it is eligible for datastream-level redirects, as specified in the formatID mapping section). The "lilly/slocum" collection has one redirect URL for item-level PURLs and another for the "rights". Some example mappings for this configuration:
The redirect URL may contain the string "(fullItemID)", which will be replaced with the object's actual fullItemID before redirection. The redirect URL may also contain the following substitution indicators:
- (pid) - The object's Fedora pid.
- (parentPid) - the pid of an object that is the parent of the target object (e.g., to resolve a page-level PURL with a rendering of the entire book turned to that page). This comes from the RELS-EXT datastream (see Paged Document Content Model).
- (pageNum) - if the target object is a page, its the page number within the parent book object. This comes from the RELS-EXT datastream (see Paged Document Content Model).
If a collection contains multiple content models, multiple item-level redirect statements may be used. Simply include a sequence number and a context model name to distinguish between the various redirects. The example below is from the Hoagy collection (paged URL is truncated for readability):
For each collection there is a "rights" url that resolves to the web page containing copyright and usage information for the collection. This PURL is in the format http://purl.dlib.indiana.edu/iudl/(collectionId)/rights
For some collections, TEI DTD documents or schema files are stored and need to be accessed though a persistent URL. These PURLs are in the format http://purl.dlib.indiana.edu/iudl/(collectionId)/resource/xml/(resource file)
PURL Resolver servlet details
The PURL Resolver servlet is Java code in the infrastructure/Purl project. It mainly consists of the single class edu.indiana.dlib.purl.PurlResolver, though it depends on libraries that were built from other infrastructure projects. A WAR file can be built with a simple ant buildfile, and dropped into an appropriate servlet container. Once the WAR file is deployed, the configuration can be edited (although it is usually better to edit the configuration in subversion, and just deploy a WAR file with the correct configuration).
For more information, see the purlResolver.conf file and the code itself.