Preservation-Ready_Digital_Collection

Group 1 LIS 60631 Sp ’15 1
The VIIIth Dynasty
Digital Repository Community Assessment
Team Members:
Troy Cherrington
Leah Crone-Magyary
Jordyn Hall
James Shaver
Tracy Skrabut
Upon consideration of the scope of our collection, we have selected educational
communities and general enthusiast as the community which will most benefit
from our collection of Henry the VIII and Court Portraiture. We anticipate that
our collection will serve the following functions:
1: Assist educators in lesson planning and illustration.
2: Provide visual aids which will assist students in identification of key
personages within the Court.
3: Offer reference aids and illustrative elements to researchers and scholars
particularly in the areas of history, art history, anthropology, fashion, and
politics.
4: Offer resources in the public domain which will be available for reuse in
papers, projects, and other educational resources under the terms specified by
their creators.
5: Provide access to information about the collections from which the images are
drawn, thus allowing community users to establish a foundation for further
investigation.
We have selected the above community for two reasons. First, because we are
students, enthusiasts, and active members of this community, our inclusion in
the target audience means that we will be better able to understand their
information needs. The community’s needs are, in a very literal sense, our needs,
and we can approach selecting metadata and information resources from the
perspective of satisfying our own information needs and, by extension, the larger
community to which we belong. It is our hope that through the creation of the
collection as well as the implementation and integration of the required
metadata, we will come to a better understanding of the particular needs of the
community as well as how users integrating digital repositories and collections
into their work make use of metadata. This greater knowledge will allow us to
expand the scope of our collection and its associated metadata to create a
repository which will have the greatest utility for our community
An additional benefit of selecting a community to which we belong and in which
we are actively engaged, is that we come from a position of being knowledgeable

Group 1 LIS 60631 Sp ’15 2
about the types of resources the community utilizes and has ready access to,
particularly as it applies to internet resources such as Wikicommons and Flickr.
Utilizing this knowledge as well as experience with existing image resources such
as image collections at museums and other cultural institutions will ensure that
we can create useful resources that play to the existing strengths and knowledge
of the community while working to build on their existing information seeking
skills.
We believe that a digital repository of images would benefit the community
because it would allow access to images and information about works which
might not otherwise be available to the community for reasons such as financial
means or geographical distance. We believe that creating a digital repository is
the first step in creating a level playing field in terms of the dissemination of
information.
Included below is a sampling of the types of metadata we will be including with
each item in the collection:
Descriptive Metadata:
Name: Name given by the artist or creator. This might not always be the official
title.
Title: Official (if known/available)
Creator: Responsible for resource.
Original Creator: If different from the creator (i.e. If this is a photograph of a
painting, who was the painter?).
Subject Matter: For the purposes of this collection, we have selected portraits of
Henry the VIII and important members of his court.
Time Period: If this is relevant to the item.
Medium: What is the medium of the item, i.e. photograph, scan, vector image,
etc.
Original Medium: This element is likely to have multiple parts, as an image could
have multiple stages in its provenance, i.e., painting to photograph, photograph
to digital scan.
Resource Location: Where was the resource sourced from? Where can it be found
now?
Original Source: Where can the original be found? (i.e. If the item is a photograph
of a painting, where is the original painting?)

Group 1 LIS 60631 Sp ’15 3
Description: A detailed description of the resource, which can encompass some of
the information sourced from other metadata elements.
Administrative Metadata:
Administrative metadata elements which provide information which will allow
image use and management. Such metadata will include but not be limited to
elements such as:
Creation date: When was the image added to the archive.
Copyright: Who holds the copyright to the images? What does the copyright allow
in terms of use?
Software: What software is necessary to view the images?
Hardware: Any hardware requirements
Provenance: Provenance of the image.
File integrity checks.
Technical Metadata:
Technical metadata elements will describe the format, processing and structure
of images. This metadata will include, but not be limited to elements such as:
File Format: What is the format of the image?
Capture Hardware Used: (i.e. camera, scanner, etc.)
Photographic image details such as ISO and f-stop (aperture)
Image format: For photographs, 35mm, medium format, born digital, etc.
Image dimensions: WxH of digital image. This should be in pixels. Dimensions of
original work are included in descriptive metadata.
Image size on disk
Series or Set: if images are collected from an existing series or arrangement of
images.

Format
Element Name element_name
Definition This is the name of the element
Examples syntax examples
Repeatability Y=Yes
N=No
Obligation M=mandatory
R=recommended
O=optional
Notes character limits, usage notes, etc.
Necessity rationale for element

Element Name original_work_depiction_people
Definition individuals represented by painting
Examples Henry VIII
Repeatability Y
Obligation M
Notes See Data Constraint field
Necessity resource discovery; descriptive metadata
Data Constraint use Library of Congress Name Authority File for preferred terms
Element Name original_location
Definition identification of place where original work is located
Examples Department of Prints and Drawings (Metropolitan Museum of Art, New
York, New York); Musée Historique du Château de Vitré (Britanny,
France)
Repeatability N
Obligation O
Notes if work is on loan, give location of current residence
Element Name original_dimensions_description
Definition dimensions, size, or scale of the work
Examples 46.5 x 38 cm (18 3/8 x 14 15/16 inches); 89 cm (35 inches) (diameter);
composed of 4 panels, 23 x 45 cm each (9 x 17 3/4 inches)
Repeatability N
Obligation M
Notes give measurements in centimeters, with inches conversion after
Element Name original_creation_date

Definition date or range of dates associated with the creation of original work
Examples 1520; 1522-1523; around 1525; 17th century; unknown
Repeatability N
Obligation R
Data Constraint use ISO 8601 standard when exact dates are known
Element Name original_creator_identity
Definition creator(s) of work that was digitized
Examples Hans Holbein the Younger; unknown, possible Norwegian; unknown
Repeatability Y
Obligation M
Data Constraint use Union List of Artists' Names (Getty's ULAN) for preferred terms
Element Name original_title_popular
Definition popular title given to original work
Examples Mona Lisa
Repeatability Y
Obligation O
Notes translations of inscribed titles will be under this element
Element Name original_title_given
Definition inscribed title given to original work by the artist
Examples La Gioconda

Repeatability N
Obligation R
Notes if given in language other than english, input native language title in
this element.
Element Name original_work_type
Definition describing the kind of work that was digitized
Examples portrait, drawing; engraving
Repeatability Y
Obligation M
Notes see Data Constraint field
Data Constraint use Art & Architecture Thesaurus for terms
Element Name access_rights_type
Definition attributes the type of rights asserted by the access_rights_owner
Examples “This image is in the public domain”; Attribution-Noncommercial-Share
Alike 2.0 license
Repeatability N
Obligation M
Notes if copyright information is unknown or unclear, use the following string:
“The depository continues researching information about this object.
Please contact regarding questions or issues.”
Necessity to ensure no copyright is being infringed
Element Name access_rights_term
Definition Defines how long depository has been given rights to display image
Examples Indefinite; 2020-01-01 through 2020-12-31
Repeatability N

Element Name capture_entity
Definition non-individual party responsible for digitization of portrait
Examples The Cleveland Museum of Art; Museum of London; History Department,
Kent State University
Repeatability N
Obligation R
Notes string
Necessity to ensure proper attribution and provide contact information for issues
Element Name capture_device_type
Definition identifier for equipment used for digital capture
Examples bed scanner, digital camera
Repeatability Y
Obligation O
Notes choose from pre-approved list
Obligation M
Notes If term does not have an expiration, assign value as “indefinite”; see data
constraint field
Data Constraint use ISO 8601 standard for representing dates and times
Element Name access_rights_owner
Definition Controller of access rights to image
Examples National Portrait Gallery, London; public domain
Repeatability N
Obligation M
Notes

Necessity technical metadata; necessary for recreating capture circumstances
Element Name capture_datetime
Definition designates date and/or time that digital image was created
Examples 2008-12-19 19:30:00
Repeatability N
Obligation M
Necessity technical metadata; for knowing how old image is and using that
knowledge to judge when to rescan (if available)
Data Constraint use ISO 8601 standard for representing dates and times.
Element Name capture_device_manufacturer
Definition identifier for manufacturer of digital capture device
Examples Sony; Panasonic; Cruse
Repeatability N
Obligation O
Notes string phrase; do not abbreviate manufacturers
Necessity technical metadata; necessary for recreating capture circumstances; also
be used to troubleshoot problems with device/scans
Element Name capture_device_modelname
Definition identifier for specific digital capture device
Examples Mekel
Repeatability N
Obligation O
Notes string
used to troubleshoot problems with device/scans

Element Name capture_device_modelnumber
Definition identifier for model number specific digital capture device
Examples TF1001
Repeatability N
Obligation O
Notes string
Element Name capture_device_modelserial
Definition identifier for specific digital capture device
Examples 1337EE555
Repeatability N
Obligation O
Notes string
be used to troubleshoot problems with device/scans
Element Name datastream_compression
Definition compression algorithm used to reduce file size of image
Examples LZW
Repeatability N
Obligation O
Notes give ratio if appropriate
Necessity will inform decompression process
Element Name datastream_compression_ratio
Definition Ratio used to compress image
Examples 10:1

Repeatability N
Obligation O
Notes
Necessity will inform decompression process
Element Name digital_dimension_horizontal
Definition horizontal measurement of digital image
Examples 1920
Repeatability N
Obligation M
Notes numerated; expressed as pixels (px)
Necessity to indicate to user the monitor specifications necessary to view image as
intended
Element Name digital_dimension_vertical
Definition vertical measurement of digital image
Examples 1080
Repeatability N
Obligation M
Notes numerated; expressed as pixels (px)
intended
Element Name digital_image_color_space
Definition Indicator of color space or color mode
Examples Black and white; grayscale; RGB
Repeatability N
Obligation R
Notes string

intended
Element Name image_bit_depth
Definition Number of bits per pixel
Examples 8; 16
Repeatability N
Obligation R
Notes numerical value
intended
Element Name software_name
Definition identifier for the software used with capture device
Examples VueScan
Repeatability N
Obligation O
Notes string
Element Name software_versionnumber
Definition identifier for version of software used with capture device
Examples 6.1
Repeatability N
Obligation O
Notes string

Element Name checksum_value
Definition Detects errors occurring in data transmission or storage
Examples Q1w2e3r4t5y6u7i8o9p0
Repeatability N
Obligation M
Notes To be pulled from dc.description.provenance field in dSpace
Necessity knowing if files have been corrupted on transfer or copy
Element Name checksum_algorithm
Definition date and/or time file was securely added to depository
Examples MD5
Repeatability N
Obligation M
Notes To be pulled from dc.description.provenance field in dSpace
Necessity knowing if files have been corrupted on transfer or copy
Element Name deposit_date_time
Definition date and/or time file was securely added to depository
Examples 2018-12-17
Repeatability N
Obligation M
Notes Pull information from dc.description.provenance field in dSpace; see
Data Constraint field
Necessity knowing how long items have been in depository
Element Name file_name
Definition name or number given to the actual digital file when it is deposited
Examples henryviiipic; 197384265

Repeatability N
Obligation M
Notes can overlap with title
Necessity alternative means for resource discovery
Element Name file_type
Definition Digital file format
Examples tif; jpeg; gif
Repeatability N
Obligation M
Notes Use extension abbreviation
Necessity to indicate the type of program necessary to view image
Element Name file_size
Definition size of digital file
Examples 1024
Repeatability N
Obligation M
Notes notation must be made in bytes
Necessity to make sure there is enough room in the depository to hold a certain
file.
Element Name archive_next_date
Definition Period of time until image to be resubmitted into depository or
reformatted to new file type
Examples 2016-03-18
Repeatability N
Obligation M
Notes Currently set to one year after initial deposit; see Data Constraint field

Element Name event_ID_type
Definition Type of event that occurred to image
Examples Ingest; capture; migrated
Repeatability Y
Obligation R
Necessity Tracking other events in lifetime of image
Data Constraint Pulled from depository-specific controlled vocabulary
Element Name event_datetime
Definition date of event that occurred to image
Examples 2005-06-07 14:14:05
Repeatability Y
Obligation R
Element Name event_detail
Definition Details of event
Examples Withdrawn by request from submitter.
Repeatability Y
Obligation R
Notes Free text string
Necessity Ensures images are still supported file types

One of the most challenging things about creating the data dictionary was breaking down
each larger element into smaller, more specialized parts. While the process became more
streamlined as the dictionary became increasingly refined, the beginning of the assignment
consisted of starting with the broadest “question” (e.g., what was used to digitize) and
determining how it could be broken down into its semantic parts. What could start as a single
question could potentially consist of 5-10 different elements. Many times, it felt as though we
were “splitting hairs” trying to break each element down as far as it could go. However, we feel
that for this particular assignment, our data dictionary will prove more than sufficient.
Once the data dictionary was complete, creating the crosswalk was “simply” a matter of
finding like terms and definitions. Characterizing the process as “simple” is a bit disingenuous,
because each data dictionary seemed to use different terms to describe the same event, or broke
down the pieces even further than some others. The challenge with creating the crosswalk was
figuring out the different terms that each dictionary used and comparing their definitions to see
if they were actually interchangeable. In creating the crosswalk for our depository, we found that
only a few elements overlapped among the different dictionaries. This was due to the elements
themselves overlapping between representing administrative, preservation, or technical
metadata.
Our particular data dictionary elements did not have a 1:1 correlation with PREMIS, but
that was expected, since the scope of PREMIS does not include descriptive and some technical
metadata. The NISO Dictionary for Digital Still Images was also used as a secondary crosswalk,
but even then some units did not have an analogous element. The remaining elements that did
not have a correlation with the prior two schemas were crosswalked with the Dublin Core
Metadata Set, which covered the remaining descriptive elements. While we were able to match
our descriptive elements with Dublin Core, our descriptive elements sometimes did not match

up perfectly. Categories for the Description of Works of Art would more closely align with our
descriptive elements due to that schema incorporating more subordinate units than Dublin
Core. There were only two elements that we could not, in good faith, find a correlation to in an
established schema. However, we do not feel this will be an issue, since the elements in question
(archive_next_date and deposit_datetime) would be automatically populated by dSpace or any
repository upon their submission.

Henry VIII Set PREMIS NISO (Still Images) Dublin Core
access_rights - - accessRights
archive_next_date - - -
capture_datetime 1.5.5.3 dateCreatedByApplication 8.2.1 dateTimeCreated -
capture_device_manufacturer -
8.3.1 scannerManufacturer
8.4.1 digitalCameraManufacturer
-
capture_device_modelname -
8.3.2.1 scannerModelName
8.4.2.1 digitalCameraModelName
-
capture_device_modelnumber -
8.3.2.2 scannerModelNumber
8.4.2.1 digitalCameraModelNumber
-
capture_device_modelserial -
8.3.2.3 scannerModelSerialNo
8.4.2.3 digitalCameraModelSerialNo
-
capture_device_type - 8.2.3 captureDevice -
capture_entity
3.2 agentName
3.3 agentType
8.2.2 imageProducer Creator
checksum_value 1.5.2.2 messageDigest
checksum_algorithm 1.5.2.1 messageDigestAlgorithm
datastream_compression -
6.6.1 compressionScheme
6.6.4 compressionRatio
-
deposit_date_time - - Date
digital_dimension_horizontal 7.1.1 imageWidth Format
digital_dimension_vertical 7.1.2 imageHeight Format
digital_image_color_space 7.1.3.1 colorSpace -
event_ID_type 2.2 eventType
event_datetime 2.3 eventDateTime
event_detail 2.4 eventDetail
file_name 1.6 originalName* - -
file_size 1.5.3 size 6.2 fileSize Format
file_type 1.5.4.1.1 formatName 6.3.1 formatName -
image_bit_depth 9.2.1 bitsPerSampleValue -
original_work_type - - type
original_creation_date - - coverage
original_creator_identity - - contributor
original_dimensions_description -
8.1.3.1.1 SourceXDimensionValue
8.1.3.1.2 SourceXDimensionUnit
8.1.3.2.1 SourceYDimensionValue
8.1.3.2.2 SourceYDimensionUnit
description
original_geographic_location - - coverage
original_title_given - - source
original_title_popular - - title
original_work_depiction_people - -
description
subject
software_name 1.5.5.1 creatingApplicationName 8.3.5.1 scanningSoftwareName -
software_versionnumber 1.5.5.2 creatingApplicationVersion 8.3.5.2 scanningSoftwareVersionNo -

THE HENRY VIIITH DYNASTY
METADATA WORKFLOW
LIS 60631: INTRODUCTION TO DIGITAL
PRESERVATION
SPRING 2015
Group Members: Troy Cherrington, Leah Crone-Magyary, Jordyn Hall, James Shaver, Tracy Skrabut

The Metadata Workflow Processes
All Henry VIIIth Dynasty community administrators in the Kent DSpace environment have the
opportunity to submit digital objects to The Henry VIIIth Portrait Collection. In order to monitor and
standardize items submitted to the collection, each new item goes through a multi-step workflow
process where items can be accepted, denied, or edited by the community administrators. This
workflow document explains this process in detail and provides step-by-step instructions for submitting,
editing, and accepting new items to the collection.
In order for items to be approved for The Henry VIIIth Collection, they must fit the following
requirements:
❖ The item must be a digital image depicting a portrait of Henry VIIIth, a member of his court, or
an immediate family member.
❖ The image must have a license that allows for non-commercial use, is a creative commons
license, or is in the public domain.
❖ The image must be of high quality and must not be a duplicate of something already in the
collection.
❖ All required metadata must be included with the image, along with as much recommended
metadata as possible. Metadata must follow the guidelines laid out in the metadata dictionary.
REQUIRED METADATA ELEMENTS
original_work_depiction_people
original_dimensions_description
original_creator_identity
original_work_type
access_rights_type
access_rights_term
access_rights_owner
capture_datetime
digital_dimension_horizontal
digital_dimension_vertical
checksum_value
checksum_algorithm
deposit_date_time
file_name
file_type
file_size
archive_next_date
FIELDS WITH DATA CONSTRAINTS
original_work_depiction_people
original_creation_date
original_creator_identity
original_work_type
access_rights_term
capture_datetime
deposit_date_time
archive_next_date
event_ID_type
event_datetime

1 THE SUBMISSION PROCESS
The Henry VIIIth Portrait Collection allows group members to submit digital objects, along with the
corresponding metadata, to the group as a whole for approval. This initial step can be accomplished by
following these steps:
1. Log into DSpace. There are two different interfaces a user can choose from, the JSP
interface (http://dspace-vm01.slis.kent.edu:8080/jspui) and the XML interface
(http://dspace-vm01.slis.kent.edu:8080/xmlui). Choose either “Login” or “My DSpace”
to find the login screen. This will take you to the VM installation of DSpace.
2. Select “Communities & Collections” from the sidebar. Collections are organized by
community and can be chosen either directly or through the corresponding community
title. The below screenshots show what the two interfaces look like. The upper one in
blue shows the JSP interface and the lower one in orange shows the XML interface.

3. Once the proper collection is chosen, select either “submit to this collection” or “submit a new
item to this collection”. Answer the initial questions that are presented and click “next”.
4. The first “Describe” section asks the user to add descriptive metadata to the digital object. This
will include the author, title, serial/report number, identifiers, type (which will always be image),
and language. Fill in all of the known metadata elements carefully. If elements are not applicable
or unknown, leave them blank. Click “Next” to continue.

5. The second “Describe” section asks the user to add subject keywords, an abstract, sponsors, and
a description of the digital item. Depending on where the digital object was obtained from,
some of this information may be available through the original resource (such as an abstract and
description). Fill in this information table carefully, leaving non-applicable elements blank, and
click “Next” to continue.

*NOTE: The “Describe” sections only contain Dublin Core elements. More metadata will be
added to the item after the submission is complete.
6. Upload a file by either typing the exact name of the file into the “Document File” box or using
the “Browse” function to locate the item on the local hard drive. Choose “Next” to check the
information and make any necessary changes.
7. The “Verify” section is an opportunity for the user to make any changes before submitting the
digital object and metadata. The “Correct one of these” buttons are available for any changes
that need to be made.
8. In order for the submission process to be complete, the standard distribution license provided
by DSpace must be granted. This step requires extreme caution and should be thoroughly
considered by the user. If the license is not accepted, the item will not be immediately deleted,
but will remain on DSpace until a decision is made to accept the license or delete the item. The
standard distribution license is shown below.

9. Once all of the above steps are complete, an email will be sent to designated group members
for the reviewing process.

2 THE REVIEWING PROCESS
The reviewing process provides a checks and balances system that allows designated group members to
check new digital items and make changes before they are finalized. Once a new item has been
submitted, an email is sent out to the group members who have permission to edit. These group leaders
are responsible for checking the item and ensuring that the required qualifications for the collection are
met, the metadata is complete, and that no mistakes or typos exist. Step-by-step instructions for this
process are listed below.
1. New items are edited through a system where items are placed into a pool where anyone with
permission can accept the task of reviewing it. To get to this pool, a user using the XML interface
(the bottom picture shown below in orange) should choose “Submissions” and a user using the
JSP interface (the top picture shown below in blue) should choose “My DSpace”.
2. To begin a review, find the new item in the list of tasks and select “take task” or “take selected
task” after checking the corresponding check-box. The task should now be in the “owned”
category.
3. If using the XML interface, the task can be clicked on to open it. If using the JSP interface, the
user should click “Perform this task”. The file should appear on the screen along with the record.
4. The user should now thoroughly examine the file and record to make sure that no mistakes have
been made, the record is complete, the file opens properly, and the item meets all collection

specifications. The user can then choose to approve, reject, do later, or return the task to the
pool.
5. If the item is rejected, the user may specify a reason for rejecting it by typing into the given
word box. This step can be completed by selecting the “reject item” button. This item will now
show up in submissions as an “Unfinished Submission” and should go back to the submission
process to be edited or removed.
6. If the item is accepted, an email will be sent to the group leaders that a new item has been
submitted and must be checked.
The next several steps are best if done by a different group leader when possible. This helps improve
quality control and gives other members a chance to review the item. The steps for checking the
submission are listed below:
7. As in the above steps, tasks can be found by choosing the “My DSpace” option from the JSP
interface or the “Submissions” option from the XML. The task should say “Check Submission” or
“Awaiting Editor’s Attention”.
8. Accept the task. The option to “Edit Metadata” should be available. As the reviewer checks each
metadata element, the option to “Correct one of these” appears as a button to the right. At this
point, only the Dublin Core elements from the Describe forms are available. The reviewer’s job is
to check these elements to make sure the data is correct and complete.
9. Once the metadata has been checked, the item can be approved, rejected, edited, or returned
to the pool. If the item is rejected, it is sent back to the submission process to be either changed
or deleted. If the item is approved, it can go to the finalization process for final approval. An
email will be sent to notify group leaders that the item has been submitted and awaits approval.

3 THE REVIEWING PROCESS
This phase is the last step before a new item is committed to the collection archive. While the same
group member can complete the Reviewing Process and the Finalization Process, it is advised that
different group members participate in these stages to improve quality control. The step-by-step
directions for this process are listed below.
1. As in the above steps, the item can be chosen as a task for approval. The task should now be
titled “Final Edit of Submission” or “Awaiting final editor’s attention”. Take the task as own and
open it.
2. The item should be reviewed to ensure that it opens properly, the metadata has no errors, and
the item fits the collection specifications. Again, the option to edit the Dublin Core metadata
from the Describe forms is available. However this time, the options are to “Add” or “Remove”
metadata rather than correct it.
3. Once the item has been reviewed and the metadata edited, the options are to “Commit to
Archive”, “Edit Metadata” again, “Do Later”, or “Return Task to Pool”. Notice that there is no
“Reject” option in the Finalization Process.
4. If the item has been committed to the archive, it will be given an identifier. An email will be sent
to the group leaders explaining that a new item has been accepted and archived with a given
identifier.
5. The item should now appear under the correct collection under Communities & Collections.
*Once the item is submitted to the collection, more metadata can be added. The Metadata Dictionary
is the guide that should be used for determining what metadata is mandatory and what metadata is
preferred or optional. These metadata elements are available when you edit an item. Below are the
steps necessary for adding this information to the digital object.
1. Find the object that has just been approved into the collection. This can be done by going to the
“Communities and Collections” page and searching or browsing for the title of the digital object.
Select it so that the record opens.
2. If using the XML interface, click on “show full item record” as shown below.

3. Once the full item record is exposed, the menu will show the option to “Edit” or “Edit this Item”.
Choose this option.

4. If using the XML interface, choose the “Edit Metadata” tab. If using the JSU interface, continue
to the next step.
5. Using the Metadata Dictionary as the guide, choose the “Name” dropdown menu to select the
metadata element you wish to add. The “Value” box can then be used to type in the data. Use
the Language box to specify what language the data is in (if applicable).
Choose “Add” or “Add new metadata” when complete.

6. The following chart shows the metadata that is mandatory, recommended, and optional for
each item.
Mandatory Recommended Optional
original_work_depiction_people original_creation_date original_location
original_dimensions_description original_title_given original_title_popular
original_creator_identity capture_entity capture_device_type
original_work_type digital_image_color_space capture_device_manufacturer
access_rights_type image_bit_depth capture_device_modelname
access_rights_term event_id_type capture_device_modelnumber
access_rights_owner event_datetime capture_device_modelserial
capture_datetime event_detail datastream_compression
digital_dimension_horizontal datastream_compression_ratio
digital_dimension_vertical software_name
checksum_value software_versionnumber
checksum_algorithm
deposit_date_time
file_name
file_type
file_size
archive_next_date
7. When all of the applicable metadata elements have been added, click the “Update” button
located at the bottom of the page.
8. Check the metadata by choosing the item from the proper collection and viewing the full item
record (as shown in step 2).
*Note: If the item needs to be edited or removed in the future, there is an “Edit” option available to
group leaders when the item is selected from the collection. From this option, the item can be
withdrawn, deleted, or edited. If the item is withdrawn from the collection, it will show up to group
leaders in the “Withdrawn Items” section of DSpace. If the item is deleted, it will no longer be
available.

THE HENRY VIII DYNASTY APPRAISAL DOCUMENT 1
The Henry VIII Dynasty
Appraisal Document Guide
LIS 60631: Introduction to Digital Preservation
Spring 2015
Group Members: Troy Cherrington, Leah Crone-Magyary,
Jordyn Hall, James Shaver, and Tracy Skrabut

Introduction
One of the most difficult facts for individuals within the archival/preservation field to accept is
that not everything can be retained. This can be particularly difficult when one is emotionally
attached to records, whether they are physical or digital in format. Appraisal is a key step in the
process of evaluating records for preservation.
This collection is composed of artwork pertaining to King Henry VIII, his immediate family, and
significant members of his court. The intention of providing such records is so that the intended
community (Tudor enthusiasts, scholars, and researchers) can access a collection of high quality
artwork.
As an appraisal guide, this document is intended to clarify how records should be located and
processed for preservation. Additionally, it details how appraisal should be conducted for The
Henry VIII Dynasty Collection.
The following topics will be covered:
1: Directions for collection submission
2: Information on permissible sources
3: Submission review process
4: Submission inquiries
5: Conditions related to submission deletion
Section I: Submitting
While The Henry VIII Dynasty Collection will be accessible for viewing purposes by anyone
with a DSpace account, only the page administrators will be permitted to add records. This
restriction is being enforced not to limit the collection, but serve to ensure that potential records
are not rejected due to missing metadata.
Due to set collection standards, it should be noted that not all images will be accepted. For
further explanation, refer to Section II.
Section II: Valid Records/Sources and Conditions of Deletion
In order for a record to be accepted to the collection, it must meet a number of requirements
before it will be considered. The minimum requirements are detailed below.
Foremost, the record must be a high-quality digital image with a resolution of at least 300 dots
per inch (dpi). The collection, based on pre-set guidelines, has been limited to images of King
Henry VIII, his immediate family, and significant members of his court. If an image does not
represent Henry VIII, his family, or his court, it will be rejected.

The image must have a license that allows for non-commercial use, a creative commons license,
or be in the public domain.1
Because the purpose of this collection is to preserve, it is essential
that the highest quality is maintained; thus, any less will not be accepted. Additionally, to avoid
copyright disputes, The Henry VIII Dynasty Collection will reject any record that does not have
a license that allows for non-commercial use.
Finally, a record will be considered valid only if it is not a duplicate of an existing collection
item. Whereas it may become challenging to prevent this as the collection grows, it should be
understood that if a duplicate is found, the image deemed to be of better quality will be retained,
and the other copy will be deleted.
Section III: Review and Inquiries
Submissions will be reviewed by the collection administrators, and they will do this by
appraising submitted records via the utilization of the worksheet found at the end of this
document. Administrators will also have the responsibility of replying to individuals who submit
records for consideration.
During the review process, individuals who submit records that appear to have value but lack
metadata can be questioned so as to gain added value. If better information is gathered from
inquiries, the record should be reappraised and added to the collection. However, if the submitter
is unable to provide sufficient required metadata and/or fails to demonstrate that he/she utilized
the metadata workflow document during the submission process, the record will be deleted.
1
Both Flickr and Google Images have filters to allow searching for such images, and screenshots at the end of this
document show how to locate these filters.

Appraisal Worksheet
Directions: Use the following questions to determine the value (appraise) potential collection
records. Based on whether a question is answered in the affirmative or negative, assign the
provided value and record it in the “Net Value” box.
Criteria “Yes”
Value
“No”
Value
Net Value
Required Information
Is the record a digital image? 5 0
Does the record have a have a license that allows for
non-commercial use?
5 0
Is the record a high-quality image (minimum 300dpi)? 5 0
Is the record a duplicate of one already in the
collection?
0 5
Is all required metadata included? 5
Subject Matter
(Include all that apply.)
Net value must
equal 25 at this
point.
Is the record an image of King Henry VIII? 5 0
Is the record an image of an immediate family member
of Henry VIII?
4 0
Is the record an image of a significant court member? 3 0
Added Information Net value must
equal at least 28
at this point.
Is the original artist known? 5 0
Is the year of creation known? (Double value if exact
year is known.)
2 0
Net
Value:

Screenshots
Flickr: Under License, select Creative Commons Only.
Google: Click on Search tools, select Usage rights, then select Labeled for reuse.

Henry VIII Dynasty Preservation Policy
LIS 60631: Introduction to Digital Preservation
Spring 2015
Group Members: Troy Cherrington, Leah Crone-Magyary, Jordyn Hall, James Shaver, Tracy Skrabut
Scope

The responsibility of the Henry VIII Dynasty Community (H8DC) is to collect and
preserve digital image files of works of art that have as their subjects Henry VIII of England, or
his family members, or significant members of his court, and to provide access to them. For
more on this, consult the Henry VIII Appraisal Document.
Purpose
The purpose of this collection is to provide students and enthusiasts with access to digital
representations of these works with relevant metadata intact in order to facilitate research and
learning. Meeting this purpose requires the preservation of these objects. The H8DC is
committed to the principles of open access. Although the collection is available to the public for
viewing, only H8DC members may submit files at this time.
Authentication
The authenticity of files contained in the digital collection is maintained by the
submission policy. Submission is limited to H8DC members whose responsibility it is to ensure
authenticity through careful application of metadata and standards as established in the Appraisal
Document and the Metadata Workflow.
The dSpace platform that is used to host the collection uses MD5 to create checksums for
each item. These checksums will be compared every six months.
Principles
The H8DC creates and maintains the digital collection according to certain principles:
● The application of best practices as determined by the wider preservation
community
● Authenticity of files and accuracy of metadata
● Open Access
● Promotion of scholarship and learning
Supported Formats

The preservation format for this collection will be the Tagged Image File Format (TIFF).
This format has been chosen for its lossless nature and its common use in the preservation
community. Files can be viewed and exported in the same format. At this time, there are no plans
to include other formats for preservation or access purposes.
Metadata Schema Used
The metadata schema used for this collection was created by the H8DC members based
on the needs of the collection and the users it is meant to serve. A crosswalk has been provided
in order to clarify metadata elements. The crosswalk equates the element names to related
elements in the PREMIS, NISO, and Dublin Core schemas. Exported metadata is in the Dublin
Core schema. Metadata will be applied in accordance with the Metadata Workflow document.
Metadata elements address various concerns related to preservation. For instance, some elements
relate to the digitization process, such as scanner model and software versions; some relate to the
original object, like dimensions and medium; while some relate to the file, such as bit depth and
pixel dimensions.
Migration/Reformatting Strategies
We are confident that the TIFF format will be relevant long into the future, but nothing
can be taken for granted in digital preservation. The community members will meet biannually to
discuss developments in digital preservation scholarship related to the selection of preservation
formats. In the event that the H8DC deems migration to be advisable, a work plan will be
developed at that time, and enacted by the community members. In addition, files will be
checked monthly to see that checksums match and that the files have not been corrupted.
Responsibility for Continued Preservation
Continued preservation will be the responsibility of the H8DC members. Though it is our
hope that a wider self-sustaining community of users will arise that will further develop and
maintain the collection according to established policy, there are no plans to implement an open
submission policy at this time.
Personnel
This is a list of the members of the H8DC and their primary responsibilities:
● Troy Cherrington: develop preservation policy, authenticity and fixity checks

● Leah Crone-Magyary: develop metadata workflow and verify metadata.
● Jordyn Hall: develop data dictionary and metadata crosswalk, technology watch
● James Shaver: develop and enforce appraisal policy
● Tracy Skrabut: community assessment and outreach
Community members work with one another to achieve collective goals, and all tasks are
completed with input from the community. Further, each group member possesses the authority
to submit, accept, and reject submissions.

Preservation-Ready_Digital_Collection

Recommended

Recommended

More Related Content

Similar to Preservation-Ready_Digital_Collection

Similar to Preservation-Ready_Digital_Collection (20)

Preservation-Ready_Digital_Collection