Remote Digital

Integrating Remote Digital Asset Management Systems

Institutions that have been curating digital collections for some time will typically have one – or more – digital repository software solutions in place. In many cases it may be desirable to leave these solutions in place. Nevertheless, the library may wish to include the digital assets among the library’s Alma inventory and allow end users to access them via Primo, while leaving your images, documents and other files exactly where they are. This scenario is supported using Alma’s Remote Digital features.

Alma supports two-way synchronization, allowing users to update metadata in either system (or both). Updates in the remote repository can be harvested by Alma, and updates in Alma can be published back to the remote repository that supports OAI-PMH harvesting. When a record is matched during MD import, Alma will not update the record if no changes are detected.

How it works

  1. Alma harvests records published by the digital repository (via file or HTTP)
  2. Alma creates a digital representation when a matching bib record is found; otherwise, a new bib record (having a digital representation) is created (using matching and normalization rules)
  3. Alma publishes to Primo; ‘View It’ is available for remote digital items

For Alma to be able to import your repository’s objects, the repository must be able to publish the objects according to the OAI-PMH protocol. So while Alma comes pre-configured for importing digital objects from some notable repositories, any repository that supports OAI-PMH and standard metadata formats can be used.

The first step is setting up your repository as an Alma Remote Digital Repository. In this area, you will need to provide information such as the metadata format your repository will be providing and the repository’s base URL which will be used by Alma as a template to create a delivery link to your object. You can also display your remote objects embedded in the Alma viewer. For more information, see the online documentation (Configuring Resource Management : Record Import : Remote Digital Repositories).

Once your repository is set up, you will need to create a Remote Digital Import Profile. This profile will be based on the remote repository configuration you just created. You will also need to provide the Alma library and collection into which the digital objects will be imported. This interface will also allow you to test your import and schedule it for recurring harvesting. See the online documentation for full details on the setting up an import profile (Configuring Resource Management : Record Import : Configuring Import Profiles).

After the import, you should be able to see your digital objects by searching Alma.

Alma will then publish your objects to Primo (unless you have suppressed your objects). In Primo’s View It tab users can access the object directly from the remote repository.

Digital Rights Management

Alma’s ViewIt service can indicate to patrons that access to a remote representations is restricted in one of two ways:

Representation Public Note: Use this field to describe the terms under which the representation can be accessed, e.g. “Embargoed until 01/01/2018”, “On-premise Access Only”. Public Note content will appear under the representation label so that users should apply their discretion when decided whether to attempt to follow the link.

Web Service: Repositories that provide a DRM web service should be configured accordingly by specifying the web service’s URL in the ‘Access Rights Template’ field of the remote repository’s configuration. When provided, Alma will send a HEAD request when constructing the ViewIt service. Alma expects one of three possible responses:

  • 403: Access is denied. A lock is displayed and link to representation is disabled. Repositories can return content in an X-Denied-Message header, which will be displayed under the representation label (instead of the Public Note). If no X-Denied-Message header is returned the default Access Denied message is displayed.
  • 401: Access is conditionally denied. A lock is displayed and link to representation is enabled. Repositories can also return content in an X-Denied-Message header, which will be displayed under the representation label (instead of the Public Note). If no X-Denied-Message header is returned the default Access Denied message is displayed. Should be used when the repository wishes to allow users to reach a the Delivery URL page (e.g. to log in).
  • 200 (or any other code): Access is granted.

Repositories that expose such a web service must allow cross-site scripting by returning CORS headers:

X-Frame-Options: SAMEORIGIN
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
Access-Control-Expose-Headers: X-Denied-Message
Access-Control-Allow-Credentials: true