Isgandar Valizada

A command-line tool for invocation of UfcMigrate has been created as a result of requests at the Hackaton in Cologne. The binaries and sources can be obtained here: https://github.com/iv10/UfcClient. The repository also contains sample digital objects in the “samples” directory. The testing can be performed on our UfcMigrate service running at http://bwfla.ruf.uni-freiburg.de host. Below in the Usage examples section you will find the location of its corresponding WSDL file.

Usage:

1. UfcClient -wsdl <url_to_wsdl> -op describe
2. UfcClient -wsdl <url_to_wsdl> -op migrate -in <fmt_in> -out <fmt_out> -do <digital_object> [-dir <file_output_dir> -name <file_output_name>]

Arguments:

•  -dir <arg>    set the directory for the resulting digital object
•  -do <arg>     file of interest subject to migration
•  -in <arg>     initial input format of the digital object
•  -name <arg>   set the filename of the resulting digital object
•  -op <arg>     operation to perform (migrate/describe)
•  -out <arg>    desired output format of the resulting digital object
•  -wsdl <arg>   URL location of the ufcmigrate WSDL file

Usage examples:

1. java -jar UfcClient.jar -wsdl http://bwfla.ruf.uni-freiburg.de:8080/psuite-pa-ufcmigrate/UfcMigrate?wsdl -op describe
2. java -jar UfcClient.jar -wsdl http://bwfla.ruf.uni-freiburg.de:8080/psuite-pa-ufcmigrate/UfcMigrate?wsdl -op migrate -in planets:fmt/ext/wpd -out planets:fmt/ext/rtf -do samples/wpd/DOB3.WPD

The GRATE-R, originally developed for PLANETS, utilises the idea of performing
 migration by interactive session replaying in emulated original environments.
 According to this approach the format migration process is carried out by
 computer interaction with the graphical user interface of the original,
 format-native applications. Their capability of exporting the loaded digital
 objects in a format other than their initial format is used. The order and
 nature of the input events necessary for this task are acquired once from the
 corresponding human interaction. The input events are then reproduced under the
 same or similar conditions for arbitrary digital objects subject to the same
 source-to-target migration. 

In a next step a prototypical service for the PLANETS IF and testbed was
 developed in the framework of a master thesis on the subject “Emulation
 Workflows in Digital Preservation” at Albert-Ludwigs-University of Freiburg
 (http://eprints.rclis.org/handle/10760/16073). On the code level it represents the implementation
 of Migrate interface of Planets IF. Its compatibility with the Planets IF
 allows it to be combined with the other preservation tools forming more
 sophisticated workflows than only migration. The integration in the Planets
 Testbed is present at our demo installation and accessible via Internet.
 

For the demonstration at the Hackathon we have prerecorded manual user sessions
 performing the sample “WPD to RTF” (Word Perfect Document) and “SAM to
 (PDF+TXT)” (AMI PRO to both PDF and text) migrations, which we will use for
 unattended migrations of real DOs. If anyone has some meaningful sample files
 to test, we would be glad to have them. We hope to make the demos accessible
 for registered OPF members after the event.

The idea of migration by emulation assumes the injection of digital objects into their native environments where they can be migrated using environment- and object native applications and the extraction of the resulting migrated objects from the corresponding environments after the process is finished.

The injection/extraction requires the usage of containers (like floppy devices), which could transport digital objects to/from the emulated environments. Currently the floppyImageHelper service within Planets provides with the ability of creating  containers in form of floppy image files.

However, in cases when the size of digital objects exceeds the size of standard floppy disks the injection/extraction of the data using them becomes a problem. Even in cases when the objects do not exceed standard floppy disk size the injection/extraction of big amounts of such objects in one turn (i.e. case of unattended large-scale migrations) becomes impossible. In order to overcome this problem the ability of creating containers of arbitrary size should be provided.

Currently we are working on the migrate implementing service, which has a similar mechanism as floppyImageHelper but instead creates HDD image files. Its responsibilities are:

• creating hdd images of a desired capacity and filesystem
• injecting digital objects into the existing hdd image file
• extracting digital objects from the existing hdd image file