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.

Currently SAML authentication in Rosetta uses the user name for mapping to the IdP.

There is no guarantee that the user name is unique within one instituiton or does not get reused after a user has left the instition. This makes the field user name ambiguous.

It gets more problematic if users from more than one IdP want to authenticate for Rosetta. This happens in a consortia setup or when guest users are stored in a separate IdP. If authentication has to be set up with more than one IdP the user name will no longer be unique and it will cause problems with authentication.

Mapping between Rosetta users and the IdP should be done by the unique identifier known as uniqueID. This ID is by definition unique even with multiple IdPs involved.

The concept of of mapping via unique-ID was used in PDS and is used in Alma.

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.

In SIP TA (Submissions – Technical Issues) it is possible to unassign a SIP that is assigned to somebody else by clicking on “Unassign”.
However, this is not possible in Permanent TA (Data Management – Technical Issues) – there is no way to unassign an IE that is assigned to another person. This can be an issue if that person is absent for a longer period and the IE remains blocked. The only possible workaround I can think of is to change the other person’s password and use his/her user account to unassign the IE – but that’s certainly not the proper way to do it. So in my opinion an "Unassign" functionality should be added in Permanent TA.

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.

After having had some issues with the new default Solr port in Rosetta 5.4.0.0, I suggest creating a startup checker plugin for Rosetta to test for Solr availability. Possible error scenarios involve:
1.) network down
2.) Name resolution down/misconfigured
3.) Solr default port closed in the local firewall / Solr not listening

1. & 2. could be checked by pinging the other servers' DNS names (NOT the IPs), which would test network availability and DNS resolution in one step. As Rosetta servers usually are located in the same subnet, we don't have to worry about ICMP firewall restrictions.
3. could be tested by using "$> telnet $HOSTNAME $PORT", like "$> telnet rosetta-host-1 8983" and SSH-ing into the remote systems to list processes listening on specific ports, like "netstat -tulpn | grep 8983" or "ss -tulpn | grep 8983".

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