We use the out of the box Update Metadata Job fairly regularly. The first part of that job is to run a publishing configuration that outputs the XML to the server. We'd like the option to exclude the file level dmdSecs from publishing, as we have some IEs with thousands and it results in a very large XML file that is difficult to work with. We generally only need to edit the IE level dmdSec so the additional XML is unnecessary.

Our Rosetta instances are all behind a firewall and accessible through a reverse proxy.

In order to sanitize our host names and improve the integration with our other services, it would be beneficiary to be able to access Rosetta in a sub-path of an existing URL. So instead of the url: test.depot.libis.be/mng/... we would like to use teneo.libis.be/depot/test/mng/...

In a preservation plan it is possible to migrate objects using external alternatives. To do this, the objects are exported, migrated externally and then re-imported.
Unfortunately it is not possible to configure the export path. Therefore it is also not possible to perform migrations separated by institution. At other places in Rosetta this is already implemented. For example, an export path can be entered when exporting an IE. To enable Rosetta's multi-client capability, it would be necessary to separate by institution when exporting in the Preservation Plan.

Hello,

we would like to limit the content delivered by a SOAP/REST request to data belonging to a certain institution.

We assume there are several ways to reach this goal.

1. A first approach could be to introduce a new argument ("institutionCode") similar to producer ID:
   <arg2 xmlns=""></arg2> //producerID
   as used in e.g. getDepositActivityBySubmitDate




2. Regarding a more fundamental solution:
   As a constortial leader we are especially interested in functionalities that support Rosetta's multi-tenancy approach.
   Therefore we would welcome a general limitation of web service request answers to content of the institution of the requesting user.

Thanks for your considerations

When you use the "Search for Objects" from the Data Management menu you can customize the columns and then export those columns easily to a CSV file. One issue we have is that only the first instance of an element is displayed and exported. For example, if we have multiple occurrences of dc:identifier only the first one will show and be exported. We would like all instances of each element to be included - perhaps with a separator like a semi-colon (or something else).

Enhance DCReplacePlugin to be able to replace empty/NULL values from the DC field replace value

The current Rosetta REST APIs return infromation about a collection structure.

We would like a REST API which will return all of the IEs attached to a Rosetta Collection

The information is currently stored in the Oracle VIEW COLLECTIONMEMBERSVIEW

Beginend from Rosetta version 5.2 functionality for Bagit must be improved in further versions. Especially a new web service for Bagit ingest must be developed, because no one want to do manual ingest per GUI interface the whole day if there are a lot of Bagits waiting to be deposited. My option is to improve submitDepositActivity so it can recognise Bagit Structure and so on. Or if it is to complicated to rebuild submitDepositActivity, than to develop a new one. Hope to see this web service in a near future. Sincerely yours, Serhiy

Would like a REST API which will retrieve a Rosetta IE METS record

You can retrieve the METS by adding 'dps_func=mets' to the delivery URL -

https://digital.slq.qld.gov.au/delivery/DeliveryManagerServlet?changelng=en&dpspid=IE305955&dps_func=mets

however, the delivery manager will not deliver the METS information if there is are access rights preventing the delivery of the digital asset

so would like a way to retrieve the METS data regardless of the access rights on the asset

By manuel ingest, the validation of Bag according to 1.0 standard, is not fully supported. It does not check the tag manifest file checksums for their correctness. Maybe there are some other holes which you can add in a comment.

as a preservation manager I would appreciate to be able to switch between the search levels IE/REP/FILE when working with Preservation Sets.
I agree, that migrations are on file level, but it would be helpful to know how many IEs/which IEs are involved in a Preservation Set. The test set also shows a list of IEs. Furthermore a lot of information for toubleshouting comes on IE-Level: view problematic IEs, view skipped objects, reports on locked IEs,...

When exporting large IEs with multiple REPs, it is hard to tell whether the export is finished or not. This becomes especially problematic when running an external automatic job which pulls IEs from the export directory before export has actually been completed.
It would be beneficial to flag a partially exported IE, e.g. via a .LOCKED file which is deleted once the export is complete.

while working with preservation plans, testing alternatives I would appreciate to have more information about problematic IEs. Error Logs like in Submissions/Technical Issues/ would be helpful. Please add "View Errors".

as a preservation manager I would appreciate to find the history of the execution of signed-off preservation plans in one place. Therefore it would be helpful to have the list of migrated IEs ( the report of event 355 - Representation was added by preservation plan) in Preservation/Preservation Executions/Signed-off Plans/Executions History/Blocks History, for example as "View Migrated Objects" in addition to "View Skipped Objects".