submitted on behalf of Michele Lindlar

Sometimes it's neccessary to update our cms metadata. if a librarian changes a record in the external cms-system, we want to update the record in rosetta too, but there's no task that works accordingly. we'd be really happy if there would be a task chain or a process that re-harvest existing cms-records.

We currently integrate two catalogue systems via SRU in Rosetta: Aleph and Pica. Both systems are integrated uni-directoinal, as in a Rosetta flag is not available in either cataloguing system. As we are integrating the union catalogues which are held by third parties, we are not at liberty of including any Rosetta-specific fields in the catalogue.

The initial CMS enrichment works without a problem. However, at times it becomes necessary to update the CMS information stored in Rosetta. This can be the case when either the catalogue was updated or when we have detected an error in our mapping.

While two tasks are available which suggest a working update - namely, "Re-Assign CMS" and "CMS Metadata Record Update" - these tasks will not re-harvest from the source CMS included in the SRU integration but will instead always pull from the physical MID copy already stored in the /metadata storage of Rosetta.
Actual re-harvesting is only possible by first manually deleting the MID record in the file storage and then re-harvesting.

ExL has provided us with a script which can be run across the file system. The script requires a list of CMS Ids first and then deletes the records from the storage. The script needs to be run by the administrator from the shell.

We do not consider the script solution sufficient. Instead, we require a functionality of re-enriching with updating CMS records from the integrated CMS system from within Rosetta.

Rosetta knows two CMS integration options: unidirectional and bi-directional. The bidirectional integration requires a Rosetta flag to be set in the CMS system. Via the flag, all Rosetta-relevant records from the CMS can be gathered and the metadata pool within Rosetta updated in bulk on a regular basis. However, institutions may be using a CMS for enrichment which belongs to a different / external institution, making the addition of a Rosetta-flag within the CMS system impossible.
This is where the unidirectional enrichment comes to play. The CMS is queried via SRU integration and records are pulled into Rosetta. The pre-requisite is that a CMS section is present within the ie.xml, containing a system name and identifier to automatically query the CMS. This works well exactly once - duirng the first enrichment of the IE from within Rosetta. While all required information to re-query the CMS is present within Rosetta, any re-enrichment attempts via Task Chains such as "Re-assign CMS" or via manual "remove" / "link" will not requery the CMS system but always pull the information from the rosetta-side shared metadata directoy containing the initial harvest. Not only is this behavior counter-intuitive, it also prohibits the update of CMS data for those institutions who do not have control over the source CMS they are enriching from.
Ex Libris has provided a script via which the re-enrichment of these records is possible. The script takes a list of CMS identifiers as an input parameter and returns newly harvested CMS records into the shared metadata folder. However, running the script requires shell access to the application servers and can therefore only be done by system administrators.
It seems that all the basic functionatily for re-enrichment is there, it's just not available in the UI. The users who typically conduct re-enrichment of CMS data, however, do not work via the shell, they work in the UI and expect the functionality to be included there.

Our idea proposed here is to make the re-enrichment mechamism avaiable via the script actionable via the UI. We urgently require this functionalilty as the experience of the past years has shown that CMS records DO change and that these changes are monitored by Rosetta staff users such as participating institutions in a consortia, who do not have sufficient rights to run shell scripts for updates.

We do not wish to have all of our institutional users in Rosetta, leaving that for administrators and publishers.

When a user has signed in successfully through SSO (in our case ADFS) we know that they are from our institution, so we should be able to do access rights rules based on this.

We are also able to pass through extra parameters through SAML to identify the type of user, and where they have come from, it would be great to be able to assign such users to basic user accounts so we can have granular access rights to IE's and Reps within Rosetta.

We at the BSB have different types of material to be displayed with the General IE Viewer (Version 5.4). We suggest to make the configuration of the General IE Viewer more flexible.

1. Configurable display of panes
In general it would be very useful to be able to configure the standard display of panes. For each the content structure pane and the descriptive metadata pane there should be three different modes of display:
Display as standard (the panes are displayed when the viewer is opened and can be closed if the viewer clicks on the grey area of the frame on the pane)
display on demand (the panes are not displayed when the viewer is opened and can be opened if the user user clicks on the grey area of the frame of the pane)
no display (one or both panes are not displayed and cannot be opened)

As the content structure may often contain confusing information like labels from the structmap set automatically by Rosetta it is necessary to be able to completely hide this pane from the user.

2. Configurable bars above the panes
As the information in the bars above the panes are also derived from the labels in the struct map and can therefore contain confusing information we suggest to allow that this information can be hidden as a configuration parameter

3. Configurable search field in content structure pane
As the search field can be confusing in terms what exactly is searched, i.e. it can be assumed that the displayed object is searched, it would be good, if there was a possibility to hide the search.

4. Allow Viewer Configuration in the Delivery Rules
As is it might be necessary to have different configurations for different types of IEs it seems useful to have the possibilty to set the configuration parameters in the corresponding delivery rules and not in one single standard configuration.

With the new IE viewer in version 5.4 the JWPlayer (for video and audio) does not have a best fit parameter meaning that the right-hand side of the player is hidden under the metadata pane. The only way to see the whole player is to close the metadata pane manually or zoom out in your browser. We would like to see a “best fit” parameter added to the JWPlayer in Rosetta so that the behavior would match the jpeg viewer (which fits itself to the frame by default).

Thanks,

Ryan Edwards
Digital Access and Systems Librarian
Information Systems
Getty Research Institute
1200 Getty Center Drive, Suite 1100
Los Angeles, CA 90049-1688
reedwards@getty.edu
310.440.7398

The migration plugin is part of preservation and is the way in Rosetta to migrate bitstreams from an obsolete format to an uptodate format. It is a script plugin receiving a file and delivering the newly migrated file.
For purpose of transparency it would be necessary to add a report about what has changed. For example when migrating pdf to pdf/a it might happen, that a font was included or even replaced. Having a report would implement a well documented preservation workflow. Depending on the migration tool the report might be quite complex.

So it would be nice to add this report as sourceMD on file level as part of the migration plugin.