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.

There is a way to have Primo index the full text of PDFs that are in Rosetta which can help a user find which Rosetta IE has a document containing their term/phrase but then once the user clicks through to the Rosetta viewer there is no way for the user to know where their search term appears. Having the search term come through to the viewer would be great, but that would only work when there are a few PDFs. For IEs that contain dozens of PDFs the user would have to open each one and search for their term. It would be great if there were a way to search the full-text of all files in an IE at once in the viewer.

Currently, when you export a file, REP or IE from Rosetta you will get an error if there is a problem with exporting the file. However, we have had at least one instance where the file seemed to export without issue but the file couldn't be opened (it was corrupt) and we were able to see that the checksum of the file did not match the checksum stored in Rosetta for that file. This helped us diagnose an issue with the way our storage layer was delivering the file. If Rosetta included an optional checksum calculation on export (the type of checksum could be specified in the export job parameters) this would make the exported files more trustworthy.

Please consider adding this feature.

Rosetta offers an IE level export task that can be used with IE level sets and exports the whole IE/Representation. What we need in addition, is a file level export task. It should be possible to export sets of files (itemized sets based on a list of FL IDs, or logical sets based on search criteria, e.g. IE PID and file extension) to a given export path. Subdirectory name could be the set ID.

To date, the only options are file download – one at time – or IE export, which means unpacking the Rep.tar containers and selecting the required files. Both options are rather tedious.

Use Cases: A user requests a set of high-resolution images for publication, e.g. several pages from a digitized book or a collection of images from different sources.

I would like an easier was to see the size of an IE/REP both in number of files and storage size. Right now, the only way I can see to get the size of the IE in terms of storage is to search at the file level for all files in that IE and then export the results to CSV and add up the size column (in bytes). Same goes for number of files except you can also see them when you’re in the Meditor in the metadata for the Rep. It doesn't seem like adding at least the number of files per REP as an option for a column in the results screen would be that difficult. Thanks!

For error-detection and workflow documentation it is sometimes necessary to be able to view all configurations in Rosetta - even all in the Administration area.
But not all users should be able to edit configuration elements in Rosetta, especially not in the Administration Area.
In our (ZBW/Germany) opinion, a view-only-user would be very handy. This person would be able to see all the configuration details and the view-option would be available to her/him, but not the edit-button.
She/he would not be able to break anything, but would be able to see all the details needed for documentation or other purposes.
This is escpecially important as sometimes configuration elements seem "to change themselves" when more than one tab in the browser is opened, even if only the view-option is selected.
Thank you

Researchers often use zip or tar files in order to upload large amounts of research data in various formats. Bytestream extraction is a useful tool for analyzing the content of these container files. The resulting bitstream information is written in the METS and displayed in the BitStreams Tab in the Web Editor. The information includes BS ID, file name, file original path, extension, mime type and format ID (if successfully identified).

We would like to suggest the following improvements for the BitStreams Tab and the bitstream information in general:

1) Include Bitstream size. The relevant values can be found in the table “HDBITSTREAMREF” in the field “FILESIZEBYTES”.

2) Display bitstreams in order of path/filename: the bitstream list should reflect the order of the files in the zip or tar file. Currently they are displayed in random order.

3) Make bitstream information searchable

Rosetta 5.2 has brought a new Storage Migration feature that enables institutions to restructure their permanent storage to fit changing requirements. However, the documentation currently warns that "Disconnecting legacy storage is not recommended as it may prevent the possibility of reverting to a previous IE version." (https://knowledge.exlibrisgroup.com/Rosetta/ProductDocumentation/Version5.2, Preservation Guide, page 185). As far as I can see, this limitation is due to the use of absolute paths in the IE XML files. The paths in older versions of these files cannot be updated without forging provenance information, which, of course, isn't an alternative. However, updating these paths would be the prerequisite for reverting to a previous IE version.

The documentation isn't clear about Rosetta's behaviour concerning older IE versions. These are the scenarios that I see:
- Rosetta might COPY older IE versions to a new storage to have the complete history stored on the new storage. The original copy on the legacy storage is kept to preserve Rosetta functionality concering version recovery.
- Rosetta might MOVE older IE versions to a new storage to have the complete history stored on the new storage. Reverting to older versions would not be possible anymore, but the legacy storage would be cleared of all files and could be removed. The complete provenance information would be kept in older versions of the IE XML, but with some invalid file paths.
- Rosetta might KEEP older IE versions on the legacy storage and write only new information to the new storage. Reverting to older IE versions would be possible, but the legacy storage could never ever be removed. You couldn't even clean up the mount points without losing access to older versions.

From my point of view, a possible way to go would be to change Rosetta's behaviour concerning file paths in the IE XML. Currently, absolute paths are used to point from the IE XML to the payload files/master images. However, using relative paths instead would make more sense here, because (at least on our storage. Comments?) IE XML files and payload files are always kept closely together anyway, so path complexity could be removed. Also, storage migrations would not make a path rewrite necessary, because the files can be addressed by the same relative path. For older IEs, that would mean that only versions created before the first storage migration cannot be reverted to. All subsequent versions would contain relative paths and could potentially be addressed even after a storage migration. For newer IEs (ingested after change to relative paths), that would mean that all versions can be addressed, even after storage migrations.

As this idea is somewhat storage specific (depending on storage layout, storage plugins etc.), I'd appreciate comments from other customers that see possible caveats. Context about SLUB's storage layout and our plans to redesign the storage can be found in the public SupportCase 00345262 "migrating permanent storage to new path [Rosetta 5.0.1.1]".

ExLibris' current mode of releasing new Rosetta versions is to announce a rough time slot ("April this year") for that new version/minor-release/servicepack/hotfix, release it and deliver a list of changes along with the new release. Up until the actual release, ExLibris will only give a very general roadmap of the planned changes. While this is an easy approach for ExLibris, it's hard for the customers to prepare for the release. Therefore, I propose for ExLibris to provide pre-release versions of Rosetta in order to enable developers to adapt their software (i.e. Submission Applications) to new features, changed API behaviour etc. These beta releases could also be used to gather customer feedback on the changes and improve features before the final release, just like it has been a best practice throughout the whole industry for many years now.

If, for any reason, the suggested developer preview releases are not feasible, I suggest that ExLibris at least releases their interface documentation for new APIs in order to enable developers to begin with their work prior to the actual release. API interfaces have to be specified very early in the design process, so they should be available early on. Developers could mock answers and write their routines before the release, and would only have to do some final tests when the actual working API becomes available.

From my point of view, both ExLibris and the community of customers would benefit from this approach.

In my opinion, the following prerequisites need to be fulfilled to implement this idea and reap the full benefits:
- smaller & more frequent patches, massively simplified/automated install process to enable fast on-site implementation
- rollback over multiple versions including DB schema (In test/dev/staging environments, the Rosetta install script could even take care of backing up the Oracle database using SSH and rman.)
- detailed change information: What new changes does the beta version contain? Which changes are in alpha/beta/release-candidate status? This includes online documentation of in-development features.
- detailed compatibility information (Which version can be installed on top of which other version? Which 3rd party tool versions are needed? Etc.)
- means of communicating development feedback that is separate from the "usual" support cases, so operational content doesn't get mixed up with development issue handling