Advanced Preservation Analysis - Advanced Digital Preservation - page 259

- having an ability formally to specify the complex relationships between
Information Objects which can be queried and examined
- having a package syntax that may provide support for preservation concepts and
terminology
- facilitating the re-use of existing RepInfo
The Packaging software component developed through the CASPAR project is a
Java API defining a set of interfaces based around the OAIS Reference Model. The
packaging component implements the NASA produced XFDU toolkit, providing
functionality to construct, manipulate and validate XFDU packages.
Loosely coupled with RORRI, the Packaging component API can interrogate the
registry to retrieve information held about a piece of RepInfo. The API can also
support operations to send and retrieve a Package to storage.
For convenience we repeat a little of the material about packaging
which appeared in earlier chapters, but here we supply some more practical
examples.
The XFDU format is focused around the idea of having a “table of contents”
called a package manifest . The manifest is an XML document that is stored within
the AIP and contains all the valuable information about the digital assets the AIP
stores. The manifest logically or physically associates the asset with its RepInfo and
PDI and can detail the complex relationships between these Information Objects
using user defined or pre-defined classifications.
Given that the manifest is XML based, it is platform independent, and can
be moved and easily exchanged and read between heterogeneous data systems.
Information can be added to the manifest to support archival curation services
such as providing information for finding aids for package discovery, digital
rights management, format migration and transformation, data analysis and data
validation.
14.11.7 Three Approaches to Packaging
A digital asset in an XFDU thus requires an XML manifest and RepInfo to be prop-
erly preserved. As stated earlier there are three approaches that could be taken to
AIP implementation:
1. Complete separation: store the manifest independently of the both data asset
and the RIN. In this situation the manifest references, through URI and Curation
Persistent Identifiers (CPIDs), to the digital asset and information stored in
RORRI respectively. The benefit of this approach is that previously archived data
does not have to be moved or modified in order to include an identifier to exter-
nally referenced representation information, as the manifest would therefore act
as a bridge between the data and the RepInfo as shown in Fig. 14.18 .TheRIN
could be separately managed and maintained to change and evolve with the needs
of the community.