Alma-Rosetta Integration Guide
This guide provides basic information on how Alma and Rosetta can be integrated in order to manage Rosetta content as Alma remote representations. Users are advised to familiarize themselves with Alma’s remote digital model before proceeding to set up any of the integration components described in this guide. This document describes two typical types of integration between Alma and Rosetta:
- Metadata management – leverage Alma’s descriptive metadata editing capabilities and publishing platform for Rosetta’s born-digital collections
- Digitization – preserve digitized inventory of your print collections in Rosetta, but manage their metadata uniformly in Alma.
These descriptions are not exhaustive. The goals of Rosetta-Alma integration vary from institution to institution, and the details will vary accordingly. This guide should therefore be regarded as a baseline which can be customized to your library’s needs.
This document addresses various aspects of setting up Alma-Rosetta interoperability. Naturally, it is intended for all stakeholders involved in this process. Some required information will come from Rosetta administration staff, and some components involve getting API access to Alma, which requires the assistance of relevant Alma administrative staff.
Rosetta is a preservation system, and that comes with the not-inconsiderable overhead of running a set of validation checks on submitted content. Libraries entrusted with the stewardship of special collections or archives should certainly consider storing digital inventory in Rosetta, or, if there are both master and derivative/access copies, storing the master in Rosetta and the derivative in Alma.
Other digital objects, such as scanned course material, is typically of a more transient nature for which preservation may be unnecessary.
For information on the licensing requirements for managing digital resources in Alma, see Licensing Requirements.
Understanding Representations
Both Alma and Rosetta use the term representation as part of their respective digital data object model. However, each system uses it differently.
A Rosetta Intellectual Entity (IE) contains descriptive metadata (file level descriptive metadata exceeds the scope of this discussion) and one or more representations, each containing one or more files.
An Alma bibliographic record, containing descriptive metadata, may contain one or more representations (and, possibly, print and/or electronic inventory). An Alma remote representation contains no files.
Setting Up Rosetta as an Alma Remote Repository
For more information, see Managing Remote Digital Repositories.
Alma is pre-configured with a number of Remote Repository instances, including two for Rosetta – one for using qualified Dublin Core and one for unqualified Dublin Core. If your Rosetta instance is (or will be) using properties from the dcterms namespace, use qualified Dublin Core.
Edit the default configuration in the three tabs:
- General Information – Customize the remote repository name (if desired) and profile Rosetta’s OAI-PMH sever URL. This is {rep.loadbalancer.host}: {rep.loadbalancer.port} /oaiprovider/request. For example, http://rosetta-backoffice.myinstitut...ovider/request. Click the Connect and Edit button to test the URL. If it is correct, a list of metadata prefixes provided by Rosetta appear. Select the prefix that provides records in qualified or unqualified Dublin Core format, depending on the rosetta remote repository instance that you selected.
- Transformer Rules – A set of mapping rules from harvested Rosetta OAI-PMH records to Alma’s representation-level object. Alma defaults should suffice for your initial setup. Refer to Alma documentation for more information.
- Delivery: Parameters that are used for delivering Rosetta content.
- Repository Name – The repository label that appears in the ViewIt page as the delivery link text.
- Object Template – A delivery URL template that is used to generate the Rosetta delivery URL. You need to set this to {rep.loadbalancer.host}: {rep.loadbalancer.port} /delivery/DeliveryManagerServlet?dps_pid=$$LinkingParameter1 (e.g. http://rosetta-delivery.myinstitutio...kingParameter1), assuming you left the default header:identifier mapping to LinkingParameter1 in the previous tab, allowing the LinkingParameter1 to hold the Rosetta PID.
- Thumbnail Template – Same as the object template, appended by &dps_func=thumbnail (http://rosetta-delivery.myinstitutio...func=thumbnail)
- Check Access Rights – Select to have the ViewIt page check access rights when displaying the delivery link to end users. If access is denied, the link is disabled, and the Rosetta access rights policy denied message appears.
Metadata Management – Born Digital Material
When a Rosetta IE is imported into Alma, its descriptive metadata becomes a bibliographic record (or is merged with an existing bibliographic record, for example, if print inventory already exists) and a single Alma remote representation is created (regardless of the number of Rosetta representations the IE holds). The Alma representation contains basic metadata such as a title in the label field, and Rosetta’s unique identifier – the IE PID. If imported via OAI-PMH, the OAI-PMH identifier is stored as the representation’s OriginalRecordIdentifier, acting as a match point for possible future updates.
Rosetta: Publishing
Exposing your Rosetta IEs to Alma is accomplished by OAI-PMH publishing, using a standard Rosetta publishing workflow. Alma expects your records to be in qualified or unqualified Dublin Core format, depending on your remote repository configuration. Be sure the publishing profile is configured accordingly. Rosetta comes out of the box with XSL configuration files that can be used for this purpose. For more information, see Rosetta OAI-PMH Integration and Publishing.
Alma: Import Profile and Job
By creating an MD Import profile, Alma can harvest OAI-PMH records published by Rosetta and create relevant remote representations. The MD Import option has the advantage of supporting ongoing updates of Alma records and inventory and should generally be preferred for born digital material where metadata is managed in Rosetta. For information on setting up an MD Import profile for the remote repository instance that you configured for Rosetta, see Managing Import Profiles.
Ongoing Metadata Synchronization
Once your inventory is created in Alma, descriptive metadata can be modified in either system, and records can be synchronized between the two systems using OAI-PMH. When setting up a metadata synchronization strategy, here are a few considerations to keep in mind:
- Editing needs – If your records contain digital-only inventory and generally require no (or infrequent) updates, prefer managing in Rosetta.
- Dublin Core support – Rosetta supports a Dublin Core application profile. Alma currently supports the Dublin Core and dcterms element sets. Depending on your Rosetta application profile, it may not be possible to manage all properties in Alma. In such cases, publishing Alma record changes to Rosetta is unadvisable, since the matched Rosetta records would be overwritten and the local fields deleted.
- MARC – Alma supports MARC, but Rosetta does not. If you have digitized print collections, they may already be cataloged in MARC. Alma supports basic crosswalking during both publishing and importing, allowing Rosetta to store a basic Dublin Core version of a MARC record. Consider the following guidelines when deciding which properties to store in Rosetta:
- Retrievability – Make sure Rosetta holds the necessary information for staff users to be able to search for the records.
- Delivery – Rosetta’s bundled viewers only display metadata that is stored in Rosetta.
- Versioning – Rosetta generates a new version every time descriptive metadata is changed. Properties that change frequently and are not vital for the reasons mentioned above should be avoided if this is a concern.
Depending on where you plan on managing your metadata, you need to set up one or both of the following:
- Rosetta to Alma publishing – A Rosetta publishing configuration and an Alma MD import job update Alma records with changes in Rosetta.
- Alma to Rosetta publishing – Set up an Alma publishing and a Rosetta harvesting Job to update Rosetta IE descriptive metadata with changes in Alma.
Digitization Flows
The Alma-Rosetta integrated digitization flow is based on a submission application that created Rosetta SIPs for digitized content and a Rosetta repository task that uses Alma APIs to create remote digital inventory for the ingested content. To support these components, perform the following steps:
- Add the following identifiers to the Rosetta Object Identifier Type code table:
Code Description ALMA_MMS Alma MMS ID ALMA_REP Alma Representation PID ALMA_REQUEST Alma Request ID - Generate an Alma API key with bibs read/write permissions.
- Configure the Alma SRU Integration Profile and set it to Active.
- Enable HTTPS communication between Rosetta (including the server running the submission application) and Alma (both the API Gateway and the Alma server).
Libraries can also create their own submission applications and/or repository task plugins, if necessary.
Alma Submission Application
The Alma submission application is used for submitting to Rosetta digitized content related to an Alma bibliographic record (and, optionally, fulfillment of a related digitization request). It is based on the Rosetta SDK and Alma bib APIs. A full description of the project and configuration instructions are available on the Developers Network. Libraries can use the application as is, or modify it to fit specific needs and workflows.
The Alma submission applications creates Rosetta SIPs for a set of files. The SIP must include a METS file with an IE-level Alma MMS ID Object Identifier type and value, which is used by the task to create digital inventory, for example:
<section id="objectIdentifier">
<record>
<key id="objectIdentifierType"> ALMA_MMS</key>
<key id="objectIdentifierValue">999999999999</key>
</record>
</section>
The METS may also contain an Alma Request ID:
<section id="objectIdentifier">
<record>
<key id="objectIdentifierType"> ALMA_REQUEST</key>
<key id="objectIdentifierValue">999999999999</key>
</record>
</section>
If the task finds a request ID, it attempts to close it if it succeeds in creating Alma inventory for the IE.
The METS must include descriptive metadata according to the selected Rosetta material flow and associated metadata validation profile. The Alma submission application retrieves descriptive metadata from Alma using SRU.
Rosetta Create Alma Inventory Task
This API-based enrichment task creates digital inventory in Alma using information coming from IEs created by the Alma submission application.
The Create Alma Inventory task is based on a bundled repository task plugin and should be suitable for most needs. Libraries with more specific needs can create their own plugins and related tasks. To run the Create Alma Inventory task, you should have an enrichment routine in place and configure your SIP processing to use it. If necessary, refer to the Rosetta documentation on how to create enrichment task chains and assign them to SIP processing configuration.
A successful Create Alma Inventory task results in the following:
- A new remote representation in Alma (see below table for additional details)
- If provided, the Alma request ID is added as a representation property, it is removed from the IE, and the request is closed (if it is in the appropriate stage).
You cannot create two Alma representations for a given IE. If the task finds an ALMA_REP identifier in the IE, the IE is ignored.
Ongoing Metadata Synchronization
It is expected that digitized material’s metadata will be managed solely in Alma. To update Rosetta with metadata changes, use the Alma publishing platform and the Rosetta harvesting job, described in Ongoing Metadata Synchronization.
Rosetta Delete Alma Inventory Task
The Delete Alma Inventory task can be manually run to delete digital inventory created incorrectly or to remove digital inventory before deleting the IE.
Rosetta Alma Inventory Task Parameters
Like all repository tasks, you have the option of configuring default task parameters at the consortium level. Here are some tips and hints for consideration.
| Name | Create | Delete | Description |
|---|---|---|---|
| Alma URL | M | M | Your Alma API Gateway URL and the API key that are used to create/delete digital inventory.
If all your Rosetta institutions are interfacing with the same Alma institution, this configuration can be shared by all tasks, allowing the benefit of sharing your API key with fewer people.
The app using the API key must have full read/write permissions on bibs.
|
| API Key | M | M | |
| Repository Code | M | - | The code you selected in your remote repository configuration. If you are using the OTB configuration, this is probably ‘ROSETTA_OAI_DC1’ (or ‘ROSETTA_OAI_QDC1’). |
| Originating Record ID Template | M | - | Determines the structure of the value that Rosetta provides for the representation’s OriginalRecordIdentifier field, appended by the IE PID. It is used primarily for matching during MD Import and should correspond to the mapping defined in the transformer rules. If you left your transformer rules as the default, this should correspond to your Rosetta OAI-PMH identifier, for example, oai:rosetta.exlibrisgroup.com:{IEPID}. |
| Library Code | M | - | The code of the library that will own the representation. |
| Usage Type | M | - | Representation Usage Type. Typically MASTER, but possibly DERIVATIVE. |
| Label | O | - | An IE descriptive metadata record property to be mapped to the representation label. Typically dc:title, dcterms:title |
| Public Note | O | - | An IE descriptive metadata record property to be mapped to the representation public note. Typically dc:rights, dcterms:accessRights, etc. |
| Default Collection ID | M | - | The collection to which the created representation’s bibliographic record will be assigned (if it is unassigned to a collection). |
| Bib Handling Method | - | M | Bib processing instructions when the representation to be deleted is the only remaining inventory. Possible values are retain/suppress/delete.
For details, see the Developer Network documentation on the delete representation API’s ‘bibs’ querystring parameter.
|
| Remove MMS ID | - | M | Removes the MMS_ID from the IE’s objectIdentifier DNX. Should generally be set to true unless there is a need to recreate Alma inventory for the record at a later time, for example, if incorrect inventory was created as a result of a misconfigured task. |
| M=Mandatory, O=Optional | |||