Up to now users needed to create PAX zips. Users would need to create a zipped folder structure, with optional XIP for fixity information, like in this example (see Using OPEX and PAX for Ingesting Content):

In Preservica 6.6.1 we are adding the ability to use PAX folders without having to zip them up, and also without having to use XIP metadata when adding fixity information OPEX is being updated to support this with :

• fixity paths
• manifest paths
• asset folders

PAX folders are a specific implementation of these which will be supported by Preservica

OPEX with Asset Folders

To support folder assets there would need to be a common way to identify them. Currently OPEX metadata files for content files sit next to them, and OPEX metadata files for folders sit inside them; we have to change this relationship slightly. In OPEX 1.2 if a folder has OPEX metadata as a sibling, then that folder must be treated as an asset. This means there is no requirement on the structure, content or metadata within a folder asset, just adding an OPEX metadata file alongside it means the following structure would be valid within the OPEX definition. We don’t place requirements on OPEX consumers to support any particular asset folder packages. A consumer should indicate if it supports a given folder asset structure and report an error if an unsupported asset folder structure is found. This allows OPEX to remain agnostic to the definition of an asset folder that may be heavily tied to the consuming system.

OPEX Schema Update

The OPEX schema has been extended to allow a OPEX metadata file for asset folders so that a single OPEX metadata file can describe the content inside an asset folder.

• The OPEX Manifest now supports relative paths inside an OPEX asset folder
• Fixities can specify what file they refer to in a relative path attribute inside the OPEX asset folder

Like all parts of OPEX these elements are not mandatory, but they are highly recommended in order to guarantee that when errors occur during the transfer of data across networks or between devices, consumers are able to stop processing and report this to a user. If a manifest element is added to OPEX metadata it must be refer to all files and folders to be ingested, which is already the case for non asset folders.

Unzipped PAX are treated as OPEX Asset Folders

OPEX processors can in principle support any asset folder structure, but Preservica can’t support arbitrary folder structures. The Preservica processing of OPEX asset folders will support unzipped PAX folder structures in Preservica 6.6.1 (the PAX format is described at Using OPEX and PAX for Ingesting Content). In order to be treated as a PAX by Preservica the folder name must end in .pax (lower case). The following unzipped PAX in the pamphlet.pax folder is a valid example of an OPEX asset folder.

and the corresponding .opex (note that all sections of the file are optional)

Existing OPEX producers

If you’re already creating OPEX, with or without PAX you don’t need to change the way you do things. However, if you want to start using complex PAX structure, or you want to simplify your existing ways of working with PAX packages, the OPEX 1.2 schema will be supported in Preservica 6.6.1 along with support for PAX packages as asset folders.