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
- Alma harvests records published by the digital repository (via file or HTTP)
- 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)
- 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. For more information about configuring an Alma Remote Repository, 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-premis Access Only”. Public Note content will appear under the reprsentation label so that users should apply their discretion when decided whether to attempt to follow the link.
Web Service (as of March 2017 Release): Repositories that provide a DRM web service should be configured accordingly by checking the “Check Access Rights” box in the remote repository’s configuration. When active, Alma will request DRM information from the remote repository when constructing the ViewIt service. This is done by sending a HEAD request to the representation Delivery URL. 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