5.2 PRESERVATION OF ACCESS AND USE SERVICES

From wiki.dpconline.org
Revision as of 08:45, 13 August 2015 by Hlhours (talk | contribs)
Jump to navigation Jump to search

An OAIS may wish to preserve a Consumer access service in the face of changing technology. To delineate some access service preservation issues and provide terminology, this subsection addresses a set of scenarios in the subsections below.

In some cases the supporting tools such as the original access and use mechanisms i.e., Content Data Object [CDO] specific software (referred to as CDO software below) that are not essential for Content Information preservation but are convenient for access, are determined to remain adequate for an extended period. However eventually this support tool CDO software will cease to function as the operating environment changes, or at least cease to function correctly, unless some action is taken. One action is to re-implement that support tool CDO software functionality in the new environment. This has no impact on the preservation of the Content Information.

Another action is to decide that it is too costly to re-implement the support tool CDO software functionality. If there is enough CDO software in this category, it may appear cost- effective to emulate the original environment and provide this as an additional support tool. This also has no effect on Content Information preservation as long as the Structure and Semantic Representation Information are maintained.

In some situations, it may be difficult or impossible to secure the necessary explicit Structure and Semantic Representation Information. In this case the maintenance of operational CDO specific software, which embodies some understanding of the Structure and Semantic Representation Information (the rest typically allocated to the operating environment), may be the only near-term practical option. Such software becomes part of the Representation Information under the Other Representation Information category. Eventually evolution of the operating environment will jeopardize the functioning of the CDO specific software. Either the Content Information will need to be transformed, thus altering both the Content Data Object and the Representation Information and requiring new CDO software for access, or emulation software supporting the original CDO software will be needed. Such emulation software logically becomes an extension of the Other Representation Information as it directly addresses Content Information preservation.

The following matrix shows the various combinations of some of the alternatives discussed above when evolution of the operating environment jeopardizes operational CDO software.

PLACEHOLDER for CDO Software role table


5.2.1 DISSEMINATION API

The first scenario assumes the Designated Community wishes to develop applications that can access AIPs using an Application Programming Interface (API) maintained by the OAIS as Access Software. The OAIS may choose to provide this API as an implementation alternative to the production and delivery of a physical DIP for dissemination. This type of service allows the Consumer, as a client, to develop applications that appear to directly access the AIPs. This sort of access could be very useful for applications such as data mining where the creation and shipping of DIPs containing large AICs is impractical. This API could allow an application to virtually navigate through an AIC, deliver the bits of the Content Data Object of selected AIUs to the application and identify locations for obtaining associated Representation Information and PDI. However, as technology evolves, the OAIS moves to new hardware, new media, and new operating systems. If the OAIS wishes to maintain the same API for its Consumers, it will need to provide a ‘wrapper’ around part of its new infrastructure to match its services to the established API. The API will need to be adequately documented and tested to ensure it correctly delivers the AIU Content Information using this new Access Software. This approach should not result in any changes to software developed by the Consumer community. When the API is applicable across a wide range of AIUs in the OAIS or there are a significant number of Consumer applications based on the API, this wrapping approach is clearly feasible and may result in a favorable cost/benefit ratio to the OAIS and its Designated Community. The ‘Layered Model of Information’ presented in annex E of this document further describes some potentially standard APIs.


5.2.2 PRESERVATION OF ACCESS SOFTWARE LOOK AND FEEL

The second scenario assumes that the Designated Community wishes to maintain the original ‘look and feel’ of the Content Information of a set of AIUs as presented by a specified application or set of applications (CDO specific software). Conceptually, the OAIS provides an environment that allows the Consumer to view the AIUs Content Information through the application’s transformation and presentation capabilities. For example, there may be a desire to use a particular application that extracts data from an ISO 9660 CD-ROM and presents it as a multi-spectral image. This application runs under a particular operating system, requires a set of control information, requires use of a CD-ROM reading device, and presents the information to driver software for a particular display device. In some cases this application may be so pervasive that all members of the Designated Community have access to the environment and the OAIS merely designates the Content Data Object to be the bit string used by the application. Alternatively, an OAIS may supply such an environment, including the Access Software application, when the environment is less readily available. However, as the OAIS and/or the Designated Community moves to new computing environments, at some point the application will cease to function or will function incorrectly.

The OAIS response to preserving an Access Software application would likely depend, in large part, on whether or not it had or could obtain the source code for the Access Software. Subsection 5.2.2.1 discusses proven methodologies for preserving application access across changes in technology. The major factors in the use of these techniques would be the cost/benefit ratio to the OAIS and the associated Designated Community. If source code or commercial bridges are not available and there is an absolute requirement for the OAIS to preserve the Access look and feel, the OAIS would have to pursue ‘emulation’ technology that is currently being researched in the Digital Library domain. This technology is discussed briefly in 5.2.2.2.

5.2.2.1 Methodologies Involving Source Code Availability

The OAIS response to preserving an Access Software application execution service would likely depend, in part, on whether or not it had the source code for the application. If the OAIS had the source code and adequate documentation on the application, the expected approach would be to port the application to the new environment and attempt to test it adequately to ensure it was functioning correctly. As described in 4.2, it may not be obvious when the application runs but functions incorrectly. Ideally all possible output values would have been recorded initially so they could be used as the basis for ensuring correct functioning following the port. However, this level of testing is likely to result in an unacceptable cost/benefit ratio for the OAIS. Given that the application was compiled from original source code, it is probable that the algorithms are correct; the production of a test suite, or reuse of a test suite that was provided with the design documentation is probably adequate. As long as there is independent Representation Information for the Content Data Object, no migration need be involved.

If the Access Software was a proprietary package, which was widely used and available commercially, it is likely that there will be commercially provided bridge (i.e., conversion) software which Transforms the current Content Data Objects to other forms used by the new Access Software having a similar look and feel. This would be a Transformation type of Migration that is likely to be Non-Reversible. If no commercial alternative is seen, the OAIS may contract with the owner of the original Access Software to develop and provide source code for a simplified tool that can read but not modify instances of data written using the format. This would also be a Transformation type of Migration because of the change in software that is providing much of the Representation Information. This approach might not be viable because of cost or legal issues. In any of these cases, the OAIS will need to establish mechanisms to verify that no preserved information has been lost. This requires that criteria have been established to clearly define what constitutes the Content Information as discussed in section 6. In addition the OAIS must investigate the issues of ensuring that the new Access Software is available to the Designated Community.


5.2.2.2 Potential Emulation Approaches

There may be a mandatory requirement from the Designated Community to maintain the look and feel of proprietary Access Software because of the large number of AIUs that are dependent on that Access Software. Proprietary Access software will not have readily available Structure and Semantic Representation Information for the Content Data Object. In this case, if the OAIS is unable to obtain the source code, or has the source code but lacks the ability to create the required application for example because of unavailability of a compiler or operating environment, it may find it necessary to investigate use of an emulation approach.

The OAIS could consider emulating the application. If the application provides a well- known set of operations and a well-defined API for access, the API could be adequately documented and tested to attempt an emulation of the application.

One approach is emulation of the underlying hardware. One advantage of hardware emulation is the claim that once a hardware platform is emulated successfully all operating systems and applications that ran on the original platform can be run without modification on the new platform. However, the level of emulation is relevant (for example whether it goes down to the level of duplicating the timing of CPU instruction execution). Moreover, this does not take into account dependencies on input/output devices.

Emulation has been used successfully when a very popular operating system is to be run on a hardware system for which it was not designed, such as running a version of Windows™ on a SUN™ machine. However, even in this case, when strong market forces encourage this approach, not all applications will necessarily run correctly or perform adequately under the emulated environment. For example, it may not be possible to fully simulate all of the old hardware dependencies and timings, because of the constraints of the new hardware environment. Further, when the application presents information to a human interface, determining that some new device is still presenting the information correctly is problematical and suggests the need to have made a separate recording of the information presentation to use for validation. Once emulation has been adopted, the resulting system is particularly vulnerable to previously unknown software errors that may seriously jeopardize continued information access. Given these constraints, the technical and economic hurdles to hardware emulation appear substantial except where the emulation is of a rendering process, such as displaying an image of a document page or playing a sound within a single system.

There have been investigations of alternative emulation approaches, such as the development of a virtual machine architecture or emulation at the operating system level. These approaches solve some of the issues of hardware emulation, but introduce new concerns. In addition, emulation research efforts often involve a centralized architecture with control over all peripherals. The level of complexity of the interfaces and interactions with a ubiquitous distributed computing environment (i.e., WWW and JAVA or more general client-server architectures) with heterogeneous clients may introduce requirements that go beyond the scope of current emulation efforts. Emulating an operating environment with a small number of applications to be supported would make testing easier and appear to offer less risk of information loss. When emulations are developed to support long-term preservation, their deployment is a logical extension of the Representation Information employed by the Access software they support. Therefore deploying such emulations is considered to be a Transformation type of Migration and the process should be documented in the associated PDI of all the AIUs.

--Please retain original text above for reference. Comment or propose amendments or additions below this line--