This presentation by Anna-Grit Eggers (University of Goettingen) offers an overview on information decapsulation and restoration. PERICLES is a four-year Integrated Project (2013-2017) funded by the European Union under its Seventh Framework Programme (ICT Call 9). http://pericles-project.eu/

1. GRANT AGREEMENT: 601138 | SCHEME FP7 ICT 2011.4.3
Promoting and Enhancing Reuse of Information throughout the Content Lifecycle taking account of Evolving
Semantics [Digital Preservation]
“This project has received funding from the European Union’s
Seventh Framework Programme for research, technological
development and demonstration under grant agreement no601138”.
Anna-Grit Eggers (University of Goettingen)

2.  Decapsulation is an integral part in the objective of encapsulation. A
user will at any point in time be able to access the encapsulated
information.
 The decapsulation process can be facilitated by
◦ appending additional information to the payload before the encapsulation
◦ storing the decapsulation supporting information at a location different to the
payload.
 Supporting information before decapsulation is called Restoration
Metadata.
 The storage location, format, and used encapsulation technique to store
the restoration metadata need to be handled in a defined way
 Sometimes it is not obvious which embedding algorithm was used, or even
if there is information embedded at all.

3. Algorithm Identifier and
Location of Restoration
Metadata

5.  An Algorithm Identifier can facilitate the identification
of the used encapsulation technique.
 It should best be stored at a defined and perceptible location
e.g. in a standard metadata field.
◦ It has to be defined which metadata field is used to guarantee the
recognition by the encapsulation and decapsulation tool.
◦ The original content of the metadata field has to be added to the
restoration metadata set, to be able to recover the object’s original
state.
 Alternatively, a visible encapsulation algorithm can be
used to store this information.

6.  For some algorithms it is necessary to store information
about the localisation of the restoration metadata.
 Some need to store other algorithm configuration options
together with the algorithm identifier.
◦ This is the case if the restoration metadata location can
vary, depending on carrier constraints and algorithm
configurations.
 The format of the localisation information can depend on the
referred algorithm.

7. “ALGORITHM_IDENTIFIER#LOCALISATION_INFORMATION”
 the “#” is a separator between the algorithm identifier and the
localisation information:
image_frame_expansion_E#582
 This translates to:
“The restoration metadata saved for the use of the algorithm that
expands images with an information frame towards east starts at
the pixel 582”.
 This information would suffice for an information encapsulation
tool to know which algorithm to use and where to find the
restoration information, and then to execute the decapsulation.

8.  It is not necessary to have an algorithm-independent format of the
locator:
audio_track_expansion#3
 Here the location information refers to the third audio track of a video
where information was embedded by adding an additional audio track to
the video.
 The localisation number at this identifier has a completely different
meaning compared to the first example
 It suffices to initiate the decapsulation process.
 Only the addressed decapsulation algorithm has to understand the
localisation information, and the IE framework has to understand the
algorithm identifier.

9.  For many information encapsulation techniques it is possible
to identify whether information is encapsulated, and which
encapsulation technique was used based on obvious traits at
the file.
 In this case it is not necessary to store algorithm identifier
and localisation information.
 Still, this information supports the handling of hardly
detectable techniques, and helps to distinguish between
similar techniques.

10. Restoration metadata

11. • A checksum of the original
 enables a validation of the restored information, carrier as well as payload
 it ensures consistency.
• Configuration information and parameters (including the
encapsulation process itself)
 needed to reverse the encapsulation algorithm
 to know at decapsulation time
 decisions made during the encapsulation process.
• Original file formats, encodings and paths of each file.
• If metadata fields are used, e.g. for the algorithm identifier, the
original entries of these fields need also to be saved.
• Localisation information, if they are needed.
• A ‘valid-until’ timestamp included in the restoration metadata can
indicate a date at which the payload has to be verified again.

12. • Other payload management information, such as semantic
annotations, to the restoration metadata can support the
handling of this information without the need to execute the
decapsulation process.
• All restoration metadata parameters have to be stored by the
encapsulation algorithms during the encapsulation process.

13. • Some embedding techniques, e.g. steganography, only
provide the restoration of the embedded payload, whereas
the carrier is not designed to be restored.
• Long-term preservation scenarios in which the carrier is a
valuable digital object require also the restoration of the
digital object.
• By storing additional information about the changes made on
the carrier digital object, and add a digit of the original digital
object, it could be possible to enable the digital object
restorability also for techniques which didn‘t originally provide
for this.