Guidelines for Digital Newspaper Preservation Readiness 17 
Section 4. Metadata Packaging for Digital Newspapers
Section 4. Metadata Packaging for Digital Newspapers 
Rationale 
Preservation  readiness  for  metadata  refers  to  the  process  of  ensuring  that  metadata  is  properly 
preserved along  with the  item/collection it  describes. Particularly in the  case of digital newspapers  - 
which  are  often  compound  objects  with  complex  relationships  -  maintaining  robust  connections 
between the metadata and the content is essential. If this information about the objects is lost, they 
may no longer be able to be reassembled and used in meaningful ways. 
In this guidance document, content curators will find practical advice regarding: 
  General strategies for packaging metadata for digital newspapers 
  Responsible approaches for exporting metadata from any existing repository systems where it 
may be held 
  Strategies for navigating the features of such repository systems 
  Tips for managing the outputs from all such activities 
Please note: this section does not provide advice on collection-level descriptive metadata creation (e.g., 
MARC, DublinCore, etc.). Institutions needing advice on that topic should refer to the host organizations 
for  the various standards and  schemas that may  apply. This  section does address  the importance  of 
creating administrative, technical, and structural metadata for long-term preservation purposes. 
Sound Practices 
Packaging  metadata  essentially  requires 
knowledge  of  three  core  factors:  1)  the 
metadata  an  institution  currently  has  for  its 
newspaper  content;  2)  where  this  metadata  is 
stored,  and 3) how this metadata is related to 
the  objects/collections  it  describes.  Each  of 
these factors will be considered below. 
1. What metadata does an institution have? 
Institutions  produce  metadata  to  aid  with 
collection  description,  discovery,  and  archival 
management.  Multiple  schemas    (e.g.  Dublin 
Core,
67
METS,
68
PREMIS,
69
MIX,
70
and  MODS
71
67
Dublin Core Metadata Initiative, “D MI Home,” 
available at: http://dublincore.org/
among  others)  are  often  used  to  record  this 
descriptive,  technical,  administrative,  and 
structural  information  for  digital  newspaper 
files and collections. Institutional practices vary 
68
Library of  ongress, “Metadata Encoding 
Transmission Standard (METS),” available at: 
http://www.loc.gov/standards/mets/
.  
69
Library of  ongress, “Preservation Metadata: 
Implementation Strategies (PREMIS),” available at: 
http://www.loc.gov/standards/premis/
.  
70
Library of  ongress, “Metadata for Images in XML 
Standard,” available at: 
http://www.loc.gov/standards/mix/
.  
71
Library of  ongress, “Metadata Object Description 
Schema,” available at: 
http://www.loc.gov/standards/mods/
.  
And paste pdf into powerpoint - software Library dll:C# Create PDF from PowerPoint Library to convert pptx, ppt to PDF in C#.net, ASP.NET MVC, WinForms, WPF
Online C# Tutorial for Creating PDF from Microsoft PowerPoint Presentation
www.rasteredge.com
And paste pdf into powerpoint - software Library dll:VB.NET Create PDF from PowerPoint Library to convert pptx, ppt to PDF in vb.net, ASP.NET MVC, WinForms, WPF
VB.NET Tutorial for Export PDF file from Microsoft Office PowerPoint
www.rasteredge.com
Guidelines for Digital Newspaper Preservation Readiness 18 
Section 4. Metadata Packaging for Digital Newspapers
widely in terms of schemas used over time, and 
also in the levels of completion or conformance 
to these schemas and their  attendant  profiles. 
Understanding  and  documenting  what 
metadata  schemas  (and  which  versions)  have 
been  used  for  different  collections  and  items 
over  time  is  the  first  step  in  readying  this 
metadata  to  be  preserved  with  the  content  it 
describes. 
2. Where is metadata stored? 
The storage and maintenance of this metadata 
likewise  varies  widely.  Most  often,  the 
metadata  is  stored  either  alongside  the 
collections  it  describes  (e.g.,  in  a  repository 
system  as  some  type  of  associated  file)  or 
embedded  with  the  objects/collections  it 
describes  (e.g.,  via  METS  or METS-ALTO
72
packaging  or  in  file  headers).  Sometimes, 
metadata  may  also  be  held  in  a  collection 
database that describes many digital collections 
held  by  an  institution  (e.g.,  one  catalog  that 
describes  the  entire  digital  holdings  of  an 
institution).  An  institution  should  document 
these  locations  within  its  digital  newspaper 
inventory  to  ensure that curators know where 
the  metadata  resides  (see Section 1. 
Inventorying 
Digital 
Newspapers 
for 
Preservation). 
3.  How  is  metadata  related  to  the 
objects/collections? 
There is a wide range of practices for metadata 
association  and  linkages.  At  the  lower  end  of 
the  spectrum,  some  institutions  document 
these  relationships  through  maintaining  a 
72
Library of  ongress, “ALTO Technical Metadata for 
Optical  haracter Recognition,” available at: 
http://www.loc.gov/standards/alto/techcenter/use-
with-mets.php
.  
metadata  spreadsheet  or  database  that 
includes  keys  or  unique  identifiers  that 
correspond to each collection title or collection 
item.  Some  institutions  fall  back  on  their 
repository  systems (e.g.,  DSpace,
73
Fedora,
74
Olive  ActivePaper,
75
or  ArchivalWare
76
 to 
structure  both  their  collections  and  their 
metadata  according  to  the  repository 
software’s  default  means  for  associating  the 
records  with  the  objects.  Still  others  package 
the  object  with  its  metadata  or  refer  to  it 
externally  using  METS  or  another  packaging 
standard. 
Understanding  the  local  range  of  metadata 
schemas, locations, and relationships is the first 
step in readying the metadata for preservation 
along with the objects/collections it describes. 
Tools
There  are  a  number  of  tools  and  approaches, 
ranging from simple  to sophisticated,  that can 
be of help in packaging metadata for preserving 
digital newspapers. 
The first is rather straightforward and relates to 
the  preservation  readiness  activity  of 
inventorying  covered  earlier  in  the Guidelines. 
For  institutions  of  all  sizes,  but  particularly 
smaller  or  under-resourced  institutions,  digital 
newspaper content may have been acquired in 
73
DSpace, “DSpace Homepage,” available at: 
http://www.dspace.org/
 
74
Fedora, “Fedora Repository,” available at: 
http://fedora-commons.org/
.  
75
Olive Software, “Active Paper Archive,” available 
at: http://www.olivesoftware.com/activepaper-
archive.html
.  
76
ArchivalWare, “Libraries,” available at: 
http://www.archivalware.net/libraries
.  
software Library dll:C# PDF Page Extract Library: copy, paste, cut PDF pages in C#.net
Ability to copy selected PDF pages and paste into another PDF file. Copy three pages from test1.pdf and paste into test2.pdf.
www.rasteredge.com
software Library dll:VB.NET PDF Page Extract Library: copy, paste, cut PDF pages in vb.
Ability to copy PDF pages and paste into another PDF file. Support ' Copy three pages from test1.pdf and paste into test2.pdf. Dim
www.rasteredge.com
Guidelines for Digital Newspaper Preservation Readiness 19 
Section 4. Metadata Packaging for Digital Newspapers
ad-hoc  ways  and  on  a  wide  range  of  media, 
particularly  born-digital  newspaper  content 
(e.g., pre-prints or web files from local presses 
and  publishers).  As such, metadata may  reside 
in multiple locations and conform to a range of 
standards  (or  even  no  standards  at  all).  The 
inventorying  stage  provides  an  opportunity  to 
record where this metadata lives relative to the 
actual  collection  files.  This  can  be  done  in  an 
inventory  instrument,  or  in  a  simple 
spreadsheet  or  a  database  used  just  for  the 
purposes  of  metadata  tabulation.  The  most 
important  task  is  recording  the  associations 
between  the  metadata  and  the  collection 
and/or  items.  More  on  what  an  institution 
should do with the outputs of such approaches 
in the next section on Essential Readiness
For  institutions  that  use  repository  software 
systems  for  their  digital  newspapers,  as 
mentioned  above,  metadata  often  is  stored 
within  these  systems  in  some  relationship  to 
the  collection.  This  metadata  may  include 
various  administrative,  technical,  and  even 
structural  elements.  More  often  than  not  this 
metadata  contains  collection-  or  item-level 
descriptive  information.  The  process  of 
extracting  and  packaging  any  such  metadata 
quite often falls to the native export features of 
the  various  repository  systems  being  used  to 
serve out the associated content. For example, 
if an institution stores its metadata in one of the 
popular repository software systems (e.g., those 
mentioned  above:  DSpace,  Fedora,  Olive 
ActivePaper, ArchivalWare,  etc),  the  software 
may  provide  metadata  export  functions  that 
can  output  the  records  as  XML.  Institutions 
should  consult  the system  documentation  and 
make  use  of  developer  support  during  this 
process  to  ensure  consistent  and  thorough 
outputs that include the full range of metadata 
elements  that  should  be  derived  from  the 
system.  Depending  on  the  purpose  of 
preservation  it  may  be  important  to  retain 
certain  data  elements  (e.g.,  Handles
77
used  in 
DSpace) for  the  sake  of  rebuilding  the 
collections at a later date in the same repository 
environment. In other  cases,  this data may be 
extraneous  to  the  long-term  goal  of  the 
institution’s preservation use case, and may be 
excluded accordingly. 
Institutions  producing  digital  newspaper 
collections according to well-formed digitization 
standards,  such  as  the  NDNP  Technical 
Guidelines,
78
will  already  have  adequate-to-
excellent  metadata  records,  including  page-
level METS or METS-ALTO records  containing 
descriptive,  technical,  administrative,  and 
structural  metadata.  In  these  cases  metadata 
may  have  been  produced  by  a  vendor  or 
digitization  unit  and  packaged  with  the 
collection  files  according to  those  well-formed 
specifications.  Such  institutions  may  require 
very  little  additional  work  to  consolidate  their 
metadata for long-term preservation. 
Institutions with  adequate resources that  have 
not yet moved beyond descriptive metadata for 
their digital newspaper collections have access 
to a range of tools that can assist with analyzing 
image, text, and other multimedia files, as well 
as extracting metadata from them for long-term 
archival management and metadata packaging. 
The  XML  outputs  of  these  tools  can  then  be 
77
Corporation for National Research Initiatives, 
“Handle System,” available at: 
http://www.handle.net/
.  
78
Library of  ongress, “The National Digital 
Newspaper Program (NDNP) Technical Guidelines for 
Applicants,” August 2012, available at: 
http://www.loc.gov/ndnp/guidelines/NDNP_201315
TechNotes.pdf
 
software Library dll:C# PDF insert text Library: insert text into PDF content in C#.net
Parameters: Name, Description, Valid Value. value, The char wil be added into PDF page, 0
www.rasteredge.com
software Library dll:VB.NET PDF insert image library: insert images into PDF in vb.net
project. Import graphic picture, digital photo, signature and logo into PDF document. Add file. Insert images into PDF form field in VB.NET. An
www.rasteredge.com
Guidelines for Digital Newspaper Preservation Readiness 20 
Section 4. Metadata Packaging for Digital Newspapers
consolidated and conformed into schemas such 
as METS and/or PREMIS. 
Below is a list of tools with varying sets of use 
cases  and  requiring  different  degrees  of 
knowledge about file specifications: 
  Unix file
79
command 
  New  Zealand  Metadata  Extraction 
Tool
80
  Exiftool
81
  File Information Tool Set (FITS)
82
For  example,  the  Unix file command  can 
produce  application  and  MIME  type  specific 
information  on  a  per  file  basis  and  can  be 
combined  with  shell  scripts  to  recursively 
perform  batch  outputs,  resulting  in  tabular 
formats  that  can  be  processed  further  for  the 
sake  of  more  long-term  supported  metadata 
schemas. 
The New Zealand Metadata Extraction Tool is a 
Java-based  graphical  user  interface  (GUI) 
application that can run on Windows and Unix 
platforms to analyze files and output findings to 
XML. 
79
LinuxQuestions.org, “file,” available at: 
http://wiki.linuxquestions.org/wiki/File_%28comma
nd%29
 
80
National Library of New Zealand, “Metadata 
Extraction Tool,” available at: http://meta-
extractor.sourceforge.net/
.  
81
Phil Harvey, “Exiftool,” available at: 
http://www.sno.phy.queensu.ca/~phil/exiftool/
.  
82
Harvard University Library Office for Information 
Systems, “File Information Tool Set,” available at: 
http://project.iq.harvard.edu/fits
.  
Exiftool is a command-line utility that can read, 
edit, and create metadata for a wide variety of 
file formats. 
FITS  is  an  open  source,  command-line  tool  for 
Unix-based systems that combines the abilities 
of  many  different  open-source  file 
identification,  validation,  and  metadata 
extraction  tools  and  that  outputs  results  to 
XML.  The  XML  does  not  conform  to  any 
formalized metadata standard, but the output is 
well  formatted  and  can  be  cross-walked  to 
METS or PREMIS as necessary. 
Readiness Spectrum
Under  the  best  of  circumstances  metadata 
should  be  created  according  to  specific 
collection  needs  but  unified  across  collections 
wherever  possible  (e.g.,  to  facilitate  greater 
discovery and/or improve an institution’s ability 
to  manage  the  content  efficiently  and 
effectively across their repository environment). 
Institutions  should  choose  metadata  schemas 
and  approaches  that  meet  focused  use  cases, 
and create metadata that they can functionalize 
and sustain. The range of metadata managed by 
an  institution  can  often  be  complicated  by 
legacy  approaches.  Over  time,  different 
curators at different moments in time may have 
made  different  choices  about  metadata 
approaches, 
leading 
to 
institutional 
inconsistencies  across  content  sets.  As  an 
institution  begins  to  ready  its  collections  for 
long-term  preservation,  it  can  impose 
consistency through mapping its metadata into 
 common  format  and  enriching  it  for 
preservation  using  the  tools  described  above. 
As  the  tools  continue  to  improve,  this 
remediation will come into reach for a broader 
range of institutions, including smaller and less 
resourced institutions. 
software Library dll:VB.NET PDF File Split Library: Split, seperate PDF into multiple
Split PDF file into two or multiple files in ASP.NET webpage online. Support to break a large PDF file into smaller files in .NET WinForms.
www.rasteredge.com
software Library dll:VB.NET PDF Page Insert Library: insert pages into PDF file in vb.
DLLs for Adding Page into PDF Document in VB.NET Class. Add necessary references: RasterEdge.Imaging.Basic.dll. RasterEdge.Imaging.Basic.Codec.dll.
www.rasteredge.com
Guidelines for Digital Newspaper Preservation Readiness 21 
Section 4. Metadata Packaging for Digital Newspapers
Essential Readiness
For institutions  with  little time,  resources,  and 
available expertise to consolidate or enrich a set 
of  diverse  legacy  schemas  across  their  digital 
newspaper collections, the  most crucial step is 
to document existing metadata practices: 
  Identify all existing metadata (note the 
standard and its version) 
  Establish the relationship between each 
metadata record and the digital newspaper 
content that it describes 
  Document  relationships  clearly  in  an 
inventory  document,  spreadsheet,  or 
collection database 
  Package  the  inventory  in  a  tabular 
format  (so  that  it  can  be  accessed  by 
multiple programs) 
  Store packaged inventory files with the 
content  that  it  references,  or  in  a  readily 
identifiable folder 
When  metadata  is  more  consistent  and/or 
supported by software systems, institutions can 
improve  their  readiness  through  exporting  all 
existing  metadata  and  packaging  it  in  a  non-
proprietary XML format  (if  not  already  done), 
and then storing such records either in a readily 
identifiable  folder,  or  in  a  folder  with  the 
content  it  describes.  Institutions  should  also 
make sure that each metadata record  has  and 
retains  identifiable  linkages  to  the  collection 
content it describes through the use of unique 
identifiers  or  other  regularized  mechanisms 
(repository software systems often assign such 
information). 
If  an  institution  is  assembling collections  from 
multiple  units  or  from  multiple  locations/ 
systems, it must ensure that unique identifiers 
will not conflict across collections. This  can be 
accomplished by adding  a unique collection or 
repository id as a prefix to every file id. 
Optimal Readiness
Optimal  readiness  involves  remediating  and 
enhancing metadata prior to the preparation of 
 Submission  Information  Package  (SIP)  for 
preservation.  It  also  may  involve  the  use  of 
METS  or  other  schemas  that  embed  the 
metadata with the content it describes. 
For those institutions that have generated METS 
and/or PREMIS metadata associated with  their 
digital  newspapers  at  or  after  the  time  of 
creation,  metadata  may  be  either  directly 
incorporated into  those  extensible schemas or 
should point to the locations where the various 
associated metadata resides. If the metadata is 
held  within  the  METS  and/or  PREMIS  records, 
these records should be retained in their proper 
locations  in relationship  to  the  collection files. 
Depending  on  the  degree  of  connection 
between referenced metadata records and the 
collection  data,  efforts  may  be  needed  to 
Case Study: Georgia Tech 
Georgia Tech participated in the NEH-funded Chronicles in Preservation project.  They  exported three 
digital newspaper collections from their DSpace repository to package them with BagIt and send them 
to project preservation partners. 
They  ensured  that  the DSpace  assigned Handle  ID for  each  object  was  exported  and  stored.  These 
Handle IDs are essential for future recovery. 
software Library dll:C# PDF insert image Library: insert images into PDF in C#.net, ASP
Import graphic picture, digital photo, signature and logo into PDF document. Merge several images into PDF. Insert images into PDF form field.
www.rasteredge.com
software Library dll:C# PDF File Split Library: Split, seperate PDF into multiple files
Divide PDF File into Two Using C#. This is an C# example of splitting a PDF to two new PDF files. Split PDF Document into Multiple PDF Files in C#.
www.rasteredge.com
Guidelines for Digital Newspaper Preservation Readiness 22 
Section 4. Metadata Packaging for Digital Newspapers
retrieve  the  external  records,  store  them 
logically  alongside  the  collection  data,  and 
ensure that the identifier linkages to that data 
are accurate. 
When  dealing  with  HTML-encoded  metadata 
for digital newspapers it may be worthwhile to 
pause  before  packaging  and  transferring  web 
files  to  make  sure  that  any  <meta>  tags  are 
well-formed  and  that  information  will  not  be 
lost  due  to  invalid HTML. Similarly,  it  can  be 
helpful to  make note  of  the  use  of  any <pre> 
tags that may be used to display  information - 
an element that is presumably not supported in 
upcoming  versions  of  HTML  (e.g., HTML5). 
Perhaps this metadata, because it is subject to a 
wide  range  of  browser  support  dependencies, 
should  be  extracted  and  saved  as  separate 
records. 
Institutions with available time and expertise to 
consolidate  and  enrich  their  metadata  should 
make  use  of  the  most  open,  lightweight,  and 
proven tools and make every effort to automate 
the process. The end goal is to create a series of 
digital  newspaper  objects  with  adequate 
technical, administrative, and - where necessary 
- structural metadata.  Using some of the  tools 
mentioned  above,  institutions  can  record 
information  about  file  formats  (technical)  and 
the  applications  that  created  them 
(administrative).  They  can  combine  this 
information  with  the  descriptive  metadata  in 
METS  records  -  perhaps  even  leveraging  the 
METS  structural  elements  (and  METS-ALTO 
where  applicable)  as  well  as  incorporating 
checksums  (see Section 5. Checksum 
Management  for  Digital  Newspapers).
Guidelines for Digital Newspaper Preservation Readiness 23 
Section 5. Checksum Management for 
Digital Newspapers
Section 5. Checksum Management for Digital 
Newspapers 
Rationale 
Stewards of digital newspapers need to be able to attest to the completeness, correctness, authenticity, 
and renderability of their collections over time. One way that institutions can do this is to require that 
checksums (digital signatures) be generated for their master digital files at the time of their creation and 
to  store  and  compare  these  checksums  over  time.  Recent  digitization  specifications  and  standards 
recommend that when institutions outsource digitization, they request listed records (or manifests) of 
files and their checksums from their vendors or digitization units and actively use these to verify their 
digitized collections upon receipt (i.e., to make sure that collections arrive intact). With this manifest of 
files and their checksums, stewards can also perform routine audits and implement repairs on corrupted 
objects from backups or preservation copies as needed over time. 
Sound Practices 
Checksums  can  be  generated  by  several  open 
source tools and utilities (more on this below), 
and can be stored in a simple txt file alongside 
the  object,  in  an  associated  metadata  object 
(e.g., METS),  in  a  manifest  with  many  other 
checksums, in  a  database, or  any  combination 
of  the  above.  Once  stored,  these  checksum 
records  can  be  called  upon  by  both  content 
curators  and  preservation  service  providers  to 
ensure  that  the  objects  have  survived  intact 
through  both  network  based  transfers  and 
hardware/software processes. 
When  recording  checksums  for  master  digital 
newspaper  files,  a  few  important  practices  to 
follow include the following: 
There are a several different kinds of checksum 
algorithms available for institutions to apply to 
their  files  (md5,
83
sha-1,
84
and sha-256
85
being 
83
A description of the md5 algorithm is available at: 
http://en.wikipedia.org/wiki/md5
84
A description of the sha-1 algorithm is available at: 
http://en.wikipedia.org/wiki/sha1
the  most  prominent).  Recording  which 
algorithm was applied is imperative so that later 
verification  processes  can  properly  apply  that 
same algorithm. 
Checksums  are  data  and  subject  to  the  same 
risks  as  any  other  data.  To  guard  against 
potential  misplacement,  loss,  or  damage,  it  is 
good practice to keep backups of checksums.  
Tools 
There are many open source tools and utilities 
for  creating  and  working  with  checksums  for 
digital newspapers. 
Examples of checksum creation tools include: 
  md5sum
86
  sha1sum
87
85
A description of the sha-2 algorithm, of which sha-
256 is a part, is available at: 
http://en.wikipedia.org/wiki/sha2
.  
86
Linuxquestions.org, “Md5sum,” available at: 
http://wiki.linuxquestions.org/wiki/Md5sum
Guidelines for Digital Newspaper Preservation Readiness 24 
Section 5. Checksum Management for Digital Newspapers
  hashdeep
88
  Fixity
89
  BagIt
90
Md5sum  and  sha1sum  are  standard  Unix 
command-line  programs  and  are  usually 
invoked on a per-file or folder basis. These can 
be  coupled  with  options  and  arguments  for 
outputting results to various formats (TXT, XML, 
CSV, 
91
etc.). 
Hashdeep  is  a  lightweight  open  source 
application  that  provides  technicians  with 
features  and  commands  for  creating  and 
comparing checksums for digital objects at both 
file  and  batch  levels.  It  includes  a  reporting 
function  that  explains  the  reason  for  a 
comparison test’s failure. 
Fixity  is  a  lightweight  program  to  automate 
checksum  monitoring.  Curators  choose  a 
regular  interval  with  which  the  tool  will 
generate checksums and compare values. Upon 
completion, reports are emailed to the curators. 
BagIt  is  a  packaging  and  transfer  specification 
that  can  be  applied  to  an  existing  set  of 
organized collection content. As a specification, 
BagIt  defines  a  data  model  called  a  bag  that 
87
Linuxquestions.org, “Sha1sum,” available at: 
http://wiki.linuxquestions.org/wiki/Sha1sum
88
Jesse Kornblum, “md5deep and hashdeep,” 
available at: http://md5deep.sourceforge.net/
89
AVPreserve, “Fixity,” available at: 
https://github.com/avpreserve/fixity
90
Descriptions of the BagIt specification are available 
at: http://en.wikipedia.org/wiki/BagIt
and 
http://tools.ietf.org/html/draft-kunze-bagit-10
.  
91
Wikipedia, “ omma-separate values,” available at: 
http://en.wikipedia.org/wiki/Comma-
separated_values
includes a folder with all the collection data and 
 manifest  of  per-file  checksums  and  file 
pathnames (see the Boston College Case Study 
below  for  an  example  of  using  BagIt  for 
checksum management). There are a number of 
existing  tools  that  can  create  bags,  such  as 
Bagger
92
and bagit-python.
93
Readiness Spectrum 
Creating  checksums  for  digital  newspaper 
content  is  a  relatively  easy  process.  For  small 
collections  and  non-technical  environments 
(e.g.,  institutions  without  technical  staff 
members), there are tools that can be used to 
calculate  checksums.  For  example,  graphical 
user  interface  (GUI)  tools  such  as  Bagger  and 
Fixity  can  make  batch  checksum  creation very 
easy  and  provide  the  institution  with  a  ready-
made  manifest  of  files  and  checksums.   The 
command-line  programs  mentioned above  are 
relatively  simple  to  invoke,  and  technical  staff 
with  even  a  moderate  level  of  experience  in 
Unix  and  Linux  environments  should  have  no 
problem coordinating the programs with scripts 
(or using  tools  like hashdeep) to automate the 
batch  creation  of  checksums  for  multiple 
objects. Others that are more platform-specific 
can also be used. 
Managing  the  checksums  you  have  created 
requires  additional  effort.  A  checksum  is  only 
helpful when  it  is used consistently over time. 
Applications will need to create new checksums 
on  demand  and  either  automatically  compare 
them  back  against  previously  recorded 
checksums  or  output them  into  a  format  that 
92
Library of  ongress, “ agger,” available at: 
http://libraryofcongress.github.io/bagger/
93
Library of  ongress, “bagit-python,” available at: 
http://libraryofcongress.github.io/bagit-python/
Guidelines for Digital Newspaper Preservation Readiness 25 
Section 5. Checksum Management for Digital Newspapers
can be processed for comparison purposes such 
as  a  comma-separated  values  (CSV).  Because 
different  tools  record  checksums  in  different 
ways, it is  important  to  be able to  access and 
migrate the data in case the tool you are using 
is  abandoned  or  better  tools  are  developed. 
Additionally,  the  algorithm  used  to  create  the 
checksums must be recorded, and it must also 
be  supported  by  the  applications  that  will  be 
used to  create  them  and/or  compare  them  in 
the future.  
Depending  on  the  scale  of  the  content  being 
managed,  and  the  degree  of  sophistication  in 
tools and approaches being used, an institution 
may want  to  document  up-front  its  checksum 
management  workflows  in  the  context  of  its 
current  or  prospective  data  management 
94
MetaArchive  ooperative, “ hronicles in 
Preservation,” available at: 
http://metaarchive.org/neh/index.php/Main_Page
.  
95
The scripts being referenced here were produced 
as a series of Interoperability Tools now available on 
GitHub at: https://github.com/MetaArchive
environment (more on this next under Optimal 
Readiness). 
Essential Readiness 
Using  Bagger  is  an  excellent  way  to  keep 
checksum  information  closely  associated  with 
the  content  for  which  it  was  created.  The 
README instructions  included  with  Bagger are 
easy to follow and allow staff to begin creating 
“bags” of collection content that will include a 
file  called  manifest-md5.txt  or  manifest-
sha256.txt.  The  manifest  file  indicates  the 
algorithm used to produce the checksums  and 
lists the file-path and checksum of every file in 
the collection. Bagged content can be routinely 
validated  with the  BagIt  tools.  The  command-
line versions of the BagIt utilities have options 
and arguments that can be invoked to perform 
specific operations such as checking for missing 
files  and  validating  checksums.  BagIt  is  a 
specification  widely  adopted  and  used  in  the 
memory  community.  A  bag  created  at  one 
institution can  be transferred and validated at 
another with ease. 
Case Study: Boston College 
In  the  NEH-funded  Chronicles  in  Preservation
94
project, several digital newspaper curators 
experimented  with  BagIt  to  inventory,  checksum,  and  package  their  collections  for  preservation 
purposes. 
Boston College packaged 183 GB of digital newspaper content using BagIt. This package was then split 
into smaller 30 GB archival units for  preservation storage using the BagIt Java Library. These  smaller 
archival units then had their checksum manifests validated against the original manifest using custom 
scripts built in the project.
95
After  a  successful ingest  into  the MetaArchive  preservation  network,  these smaller  BagIt  units  were 
exported, rebuilt, and validated as the original 183 GB package using some additional custom scripts 
built in the project. The rebuilt BagIt package was then returned to Boston College who were able to 
validate checksums using the BagIt tools. 
Guidelines for Digital Newspaper Preservation Readiness 26 
Section 5. Checksum Management for Digital Newspapers
AVPreserve’s  Fixity tool  provides  another easy 
way  to  create  and  monitor  checksums  over 
time.  An  institution  with little  to  no access to 
technical staff or expertise can follow the User 
Guide  and choose  to  validate  checksums  on  a 
daily, weekly, or monthly schedule.  A manifest 
listing  the file-path  and checksum of every  file 
in  the  collection  is  stored  as  a  CSV  in  the 
program’s  directory.  When  the  tool  runs,  it 
generates  new  checksums  and  compares  the 
values  to  those  in  the  manifest.  After  the 
validation,  an  email  is  sent  to  up  to  seven 
recipients  reporting  whether  files  have  been 
added, renamed, deleted, or corrupted.  
Optimal Readiness 
For institutions with more time, resources, and 
expertise, command-line programs like md5sum 
or  sha1sum  will  provide  more  flexibility 
regarding  the  application  of  the  task  and 
control over the output format (BagIt gives you 
 quick  solution  but  has  some  mild 
dependencies  on  the  BagIt  utilities).  As 
mentioned  previously,  there  are  also  versatile 
tools such as hashdeep that can facilitate batch 
creation of checksums, and that provide a suite 
of features for comparing checksum digests. 
After checksums have been created, they must 
be properly managed over time. An  institution 
should store its checksums in secure  locations, 
developing logical schemas and approaches for 
associating checksums to the digital newspaper 
objects  for  which  they  were  generated,  and 
establishing  reasonable  schedules  and 
workflows  for  creating  checksums  and 
comparing  them  back  against  their  previously 
generated  counterparts.  Because  checksum 
validation  is  a  task  that  must  be  performed 
regularly,  it  should  be  automated  as  much  as 
possible,  whether  with  operating  system 
features  such  as  cron
96
in  Unix  environments 
and scheduled tasks
97
in Windows or as part of 
 larger  repository  environment.  Establishing 
regular  audit  and  reporting  schedules  and 
enforcing these within the institution’s broader 
digital preservation policy helps to  ensure that 
the practice  is carried out  routinely over time. 
Audit schedules should be logical and take into 
consideration  the overall  amount  of  data  that 
needs  to  have  checksums  generated  and 
compared  at  any  given  interval  (checksum 
creation 
and 
comparison 
operations, 
particularly  when  involving  large  amounts  of 
data,  can  be  time  and  CPU  intensive).
96
Linuxquestions.org, “Scheduling tasks,” available 
at: 
http://wiki.linuxquestions.org/wiki/Scheduling_tasks
97
Microsoft, “Schedule a task,” available at: 
http://windows.microsoft.com/en-
US/windows/schedule-task
Documents you may be interested
Documents you may be interested