we are using the Rosetta-Aleph-Integration in both directions:
1. creating the CMS-record in Rosetta and
2. setting the Rosetta-flag in Aleph as well as updating the Aleph record with the URN created in Rosetta.
In the past there was only one target field for the URN and the assignCMS task with updateURNTask worked without problems.

Due to changes in the cataloging rules - we are using now the international RDA-rules - we have to deal now with different target fields in Aleph for the URN depending on the type of material: e-only e-books, digital reproductions of printed books, online versions of printed books, etc.

The target field is configurable in the Rosetta-Aleph-Sync, but this is not sufficient with the new situation. We want to be able to configure profiles for the updateURNTask depending on the material type: to specify the target MARC-field, to populate subfields with fixed information depending on the material type and with the URN.

(It is not possible at the moment to update the URN in a subfield of an already existing field, a new field is created (case 00510676)).

Astrid Schoger on behalf of the Bavarian State Library

As a Preservation System, Rosetta does not record any detail relating to Derivative Copy content in the METS. This is not inconsistent with Digital Preservation philosophy, but it does mean that Derivative Copy contents cannot be discovered using a Search Query or API calls from external applications. This seems to conflict with Ex Libris’ spruiking of Rosetta as a DAMS, since all content within a traditional DAMS (including Derivative material) can to be searched and accessed using standardized queries. If the DAMS operability is going to be further developed in Rosetta, will Ex Libris add further functionality to discover Derivative Copy content outside of having to open an IE in the Web Editor? This current drawback is one of the main reasons that we at SLNSW are opting to use another application to act as a DAMS (delivery/discovery), and use Rosetta as a Dark Archive for actual preservation material only.

Save Set information for repeated Processes

When setting up a recurring Process that uses a Set with different values each time, Rosetta does not keep a record of the Set values each time it is generated, so that you cannot Rerun the previous Process instances in History. We propose a change to the recording of Set metadata so that each time a Set is used, its values are stored, thus allowing a Historical Process to be rerun at a later date. An example is rolling fixity checks, wherein a different range of SIPs are checked each day using the same Process. By saving the SIP range each time, any Process instance in the History can be rerun if necessary at a later date.

We are looking at supporting the ability to add a new format to our Ingest tool, in conjunction with this we would like that to trigger some type of API call to Rosetta and add the file format as an allowed format as well.

In Rosetta you can add a new file extension in the Submission Format area of the UI. We have provided the option to add a new format in our Ingest tool, So once they do this, we would like this to trigger an some type of API call to Rosetta and add the new file extension as an allowed file extension without having to go into the UI and add the file extension manually in the Submission Format location.

hen running a Publishing Sync Job and looking at the assciated 'View' we get the following information

Mon Jan 07 09:06:40 AEST 2019 INFO sync all configurations for IE publishing
Mon Jan 07 09:06:40 AEST 2019 INFO sync the configurationId: 18981614
Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 18981613
Mon Jan 07 09:06:41 AEST 2019 INFO Handling new IEs
Mon Jan 07 09:06:41 AEST 2019 INFO Handling Removed IEs
Mon Jan 07 09:06:41 AEST 2019 INFO Handling updated IEs
Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for the profileId: 18981613
Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for configurationId: 18981614
Mon Jan 07 09:06:41 AEST 2019 INFO sync the configurationId: 20975335
Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975337
Mon Jan 07 09:06:41 AEST 2019 INFO Skipping Profile: 20975337 because it is inactive.
Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for the profileId: 20975337
Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975338
Mon Jan 07 09:06:41 AEST 2019 INFO Skipping Profile: 20975338 because it is inactive.
Mon Jan 07 09:06:41 AEST 2019 INFO Finished sync for the profileId: 20975338
Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975389
Mon Jan 07 09:06:41 AEST 2019 INFO Handling new IEs

This is Ok but the additional information 'name/label' would be helpful

For example in the above -

Mon Jan 07 09:06:40 AEST 2019 INFO sync the configurationId: 18981614

the informatin would be better dispayed as follows

Mon Jan 07 09:06:40 AEST 2019 INFO sync the configurationId: 18981614 (Handle Publishing)

where 'Handle Publishing' relates to the 'Data Management: Publishing Configuration | Details | General Details | Name'

Another example

Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975337

the infomation would be better displayed as

Mon Jan 07 09:06:41 AEST 2019 INFO sync the profileId: 20975337 (Rosetta2Alma)

where Rosetta2Alma is the filed located in 'Data Management: Publishing Configuration | Details | Profile Details | Name'