How can we improve Rosetta?

Validation Stack to Flag Problems as Warnings, not Errors, and Move them to Permanent

Ability to run the validation stack during ingest, but only flagging warnings, not errors. All IEs will be moved to the permanent repositories and if needed, the problems will be dealt with in a future stage.

20 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
AdminAdi Alter (Rosetta Product Manager, Ex Libris, Ex Libris) shared this idea  ·   ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • AdminDaniel Greenberg (Product Manager, Ex Libris) commented  · 

    Hi Teresa et al,
    Please let me know if this issue can be closed. We have quite a strong preference not to provide an additional, "easy" method to categorically ignore all errors, so please let me know if the workaround is sufficient.
    Thank you,

  • Teresa Soleau commented  · 

    We have found a workaround for this. You add a rule to the end of the list of rules to ignore the error. For file extension mismatch errors the ignore rule lists "Any" for all of the Input Parameters and then for Output Parameters it assigns fmt/unknown to that file. I imagine you could do the same thing for TechMD extraction errors.

    Regarding comment from Andreas: We do not have the resources to resolve these issues as they arise and we are only using this for born-digital material where we wouldn't be "fixing" them anyway (we keep the files as we received them). We think that having them in the repository even without validation is useful because they can have fixity checks and be redundantly stored - plus, many of the files in the batch DO get identified as part of the validation stack.

  • Andreas Romeyke commented  · 


    this is a bad idea, I think. The reason to use a validation is

    - to know the risk about IEs in archive
    - to deny/sort broken files out

    The rosetta system has already a quarantaine zone to deal with problematic files, which is the TA workbench.

    The purpose of the TA is to repair broken data as early as possible in the archiving process. Moving broken files into the permanent repository contradicts this paradigm.
    With best regards


Feedback and Knowledge Base