We have a growing number of deposits where data enters the archive in container formats such as .zip and is usually not extracted for various reasons. Examples include zip containers which are part of a larger complex object IE such as the content of a CD or a as zipped supplementary data to a journal article where the zip container is referenced from with the publication.

In this case, files in BYTESTREAM are extracted during ingest for metadata extraction, but are stored as container formats in permanent. But there are some shortcomings compared to the regular validation stack:

• no validation takes place
• techMD extraction takes place but is only stored in very limited form
• no fixity checksum is created for files in bytestream

On the container-level itself – so the file level for the object in question – everything takes places as expected.

We therefore suggest, to run the full validation stack on objects in BYTESTREAM, which includes:

• validation
• full techMD extraction
• virus check
• creation of fixity checksums

I have been running the system checks via the 'Rosetta Administration' -- when the job runs to completion you do not get an alert that the job has completed with no issues other that the 'No records were found' message

This may cause confusion especially if when accessing the 'System Checks' the message 'No records were found' is already being displayed

This is not an issue but it would be nice to get feedback that after running the system checks that no issues were found.

It may even be great to get a checkbox against each of the actions showing success

we are using access restriction on file level for some of our items. For PM REP we can assign this automatically via task chain, but this approach does not work for AD REP (tasks cannot be used). Unfortunately when there are files in PM REP with access restriction, this access restriction is not inherited/copied to AD REP during the enrichment process. So we need to go to AD REP and manually add/change the AR for the files which need to have it.
It would be great if we have either have a task chain which would copy the file restrictions from PM or MM REP to AD rep OR enrichment routine would be able to do this (another task in enrichment?)
cheers

The IE delivery rule list contains the following fields:
- active
- name
- description
- creation date
- modification date
- commands view, edit and delete

the dates and commands take up half of the screen, not leaving much space for the name and description. Both these fields are rarely descriptive enough to fully understand the implication of the rule and we have had several occasions where an operator added a rule, changed the order or modified a rule without understanding its impact. Resulting in wrong viewers being used or even files not viewable at all.

We think the list can be improved by removing the date fields, which - at east for us - have little value and condense the action columns. The newly gained column space could be used to display the information from the input parameters in a structured way. I believe that would improve the insight on the impact of a rule right from the list.

We have similar thoughts about the SIP routing rules list. Possibly it could be a suggestion that applies to all rules lists in Rosetta and/or all order-dependent lists.

Currently the material flow combines amongst others, a restrictive list of access rights, retention policies and metadata fields. These operate as restrictions on which access rights, retention policies and metadata fields can be supplied by the submitter. We suggest to make it possible to opt-out on any of these restrictions. That would benefit customers that have automated submission workflows outside of Rosetta where the metadata is already checked for validity and fully under control. It would also help solving human errors when new ARs are created, but forgotten to be added to their respective material flows. If it not possible to opt-out, it would be nice to have 'I do not care' or 'Anything' entries in the access right and retention policy list that do basically the same. For us personally, relaxing the access right restrictions would be the biggest win.

As part of the CSV/Zip deposit method, Rosetta verifies that all files in the CSV are in the Zip. It does not, however, check if all files in the Zip are listed in the CSV.

We recently discovered that for 5 of our IEs, the CSVs were incomplete and missing a few thousand files. Even though the Zips contained more files, the deposits went through successfully and the files not listed in the CSVs were not preserved.

I propose that as part of the deposit process, Rosetta checks the number of files in both the CSV and Zip and verify that they match.

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.