** At the most basic level we would like to ensure that the system migration does not result in the loss or alteration of any archived objects. In the case of a pure medium migration this could be realised very easily using checksums. More sophisticated mechanisms are needed for migrations where, as an example, AIPs that are held together in a physical container (e.g. a TAR file) on the source system need to be taken apart and subsequently re-assembled on the destination system. In that case we will need to check the integrity of each single file within the AIP, before and after the migration.
** Possible issues: Due to the wide variety of legacy, publicly available and custom-built archiving systems that are used by different repositories, and the resulting variety of data models and structures, it may be difficult to establish use cases that are sufficiently generic to be of interest to more than one SCAPE partner. The best approach may be to start out with a limited number of relatively simple, generic and universally applicable use cases, such as: Migrate one object from one medium to another and verify the integrity of migrated object. Migrate set of files from one container file to another and verify the integrity of all constituting components. We could then establish a checkpoint where, based on the outcome of the work on the above simple use cases, we decide whether continuing the work on this scenario is worth any further effort or not. A more thorough understanding of the problem space (including key aspects for validation) would in itself be a useful output here.
* EXL
** This scenario sounds like a requirement for AIP migration. There has been some recent work in this area. See this [paper|http://fclaweb.fcla.edu/uploads/is_and_t-pawletko-caplan-final.pdf].
* KEEPS
** Watch can contribute to the solution with the triggers:
*** Monitor new repository systems or new versions of existing ones
*** Monitor repository systems features and tools
*** Monitor repository systems popularity and support
*** Monitor operative systems
*** Monitor policies (policies may require functionality that is not supported in current repository system) |
| *Context* | Ideally this should be a representative cross-section of AIPs in a repository. However, the solutions that are needed for this scenario will most likely be highly dependent on the data (and metadata) models used by the source and destination systems, as well as on the specific hard\- and software infrastructures. \\
At the time of writing, KB is exploring making a dataset of AIPs available. |
| *Lessons Learned* | _Notes on Lessons Learned from tackling this Issue that might be useful to inform the development of Future Additional Best Practices, Task 8 (SCAPE TU.WP.1 Dissemination and Promotion of Best Practices)_ \\ |
| *Training Needs* | _Is there a need for providing training for the Solution(s) associated with this Issue? Notes added here will provide guidance to the SCAPE TU.WP.3 Sustainability WP._ \\ |
| *Datasets* | \\ |
| *Solutions* | |
h1. Evaluation
| *Objectives* | _Which scape objectives does this issues and a future solution relate to? e.g. scaleability, rubustness, reliability, coverage, preciseness, automation_ |
| *Success criteria* | _Describe the success criteria for solving this issue - what are you able to do? - what does the world look like?_ |
| *Automatic measures* | _What automated measures would you like the solution to give to evaluate the solution for this specific issue? which measures are important?_ \\
_If possible specify very specific measures and your goal - e.g._ \\
_ \* process 50 documents per second_ \\
_ \* handle 80Gb files without crashing_ \\
_ \* identify 99.5% of the content correctly_ \\ |
| *Manual assessment* | _Apart from automated measures that you would like to get do you foresee any necessary manual assessment to evaluate the solution of this issue?_ \\
_If possible specify measures and your goal - e.g._ \\
...