emulationServicesFAQViewpaths

About view-paths

View-paths are a possibility to formalize the steps involved for object rendering/access. They could be used to define requirements regarding emulators, additional software components (see the section on the emulation Software Archive for example) and reference environments like GRATE. In later extensions metrics/measurements could be introduced.

Overview

Having an emulator and contextual information contained in a view-path still leaves some implications before the digital object can be rendered. First, the digital object has to be characterised which may be difficult if the object is not a single file but a group of files forming a program. Then, depending on the emulation level a number of additional software (secondary) objects like applications, operating systems, helper programs and drivers are to be taken into account. There might exist different view-paths for each object type and this will increase with the number of object types.

A view-path defines ways for software setup starting from the object (type of, e.g. read by PRONOM or tools like Unix file), covering the rendering application (viewer if needed), the operating system required by the object or the OS and the emulation or virtualization tools needed. However, no matter which emulator is chosen, contextual information of the computer environment is always required. For example, questions such as "for which operating systems is Wordperfect 5.1 compatible?" are less obvious today then twenty years ago.

To overcome this gap of missing knowledge, a formalization process is needed to compute the actual needs for an authentic rendering environment of the digital artefact. In 2003, IBM Netherlands proposed the concept of a view-path based on their preservation layer model. In the end most or at least some of the more difficult steps of view-path generation should be automated The view-path would start from the DIP retrieved from OAIS archive. After the successful setup of the view-path the object has to be transported into the chosen environment. This procedure will heavily depend on the type of emulation (strategy, level).

Depending on the emulation level a number of additional software (secondary) objects like applications, operating systems, helper programs and drivers are to be taken into account. These components have to be combined together in a structured approach to recreate the original or an equivalent rendering or execution environment of the object in question. Depending on the object type and chosen level of emulation the view-path is of different length. Thus are view-paths the central glue elements to be discussed in more depth.

Having an emulator and contextual information contained in a view path still leaves some implications before the digital object can be rendered. First, the digital object has to be characterised which may be difficult if the object is not a single file but a group of files forming a program. Then, depending on the emulation level a number of additional software (secondary) objects like applications, operating systems, helper programs and drivers are to be taken into account. There might exist different view-paths for each object type and it will increase with the number of object types.

Implications of View-paths on OAIS

For environment re-creation of all objects stored in OAIS archive there are some implications. The classification of the ingested object and the generated meta data influence the needed steps for the later access. Beside this the criteria of view path determination may vary depending on the targeted user group or archival institution. In general three major phases could be distinguished:

• Store in an emulation Software Archive for view path generation (emulators, operating systems, viewer applications, helper programs for host and target systems). An important part of the archive management is the selection of the proper emulators.
• On ingest it should be checked if a view path is available for the object. For the detection of digital object types are several strategies in place. The most prominent one at the moment is the PRONOM database and DROID tool of TNA. This information might have to be extended with tool information like on applications or operating systems along the view path: A registry would be needed for description and dependencies of available tools and environments.
• OAIS management should regularly check if all view paths for all stored objects are still available. In the moment of digest the work steps for the object rendering are to be presented and than executed automatically or with the interaction of the archive user or archivist. These work steps not simply copy and reproduce the objects bit stream but actually allow an access to the object in a sensible way. At this point emulation and migration strategies do not differ much: The procedures for the object reproduction could be both described by the aforementioned view paths. Additionally, different view-paths (one for the migrated object and one for the emulated object) may help to ensure the authenticity.