HighLevelPolicies - Revision history

Jlderidder at 15:31, 14 December 2012

2012-12-14T15:31:44Z

Jlderidder at 14:17, 30 September 2011

2011-09-30T14:17:26Z

←Older revision		Revision as of 14:17, 30 September 2011
Line 24:		Line 24:
	# Assessing which of our selected technical metadata fields (from MIX, for images: [http://www.loc.gov/standards/mix/] and AudioMD for audio: [http://www.loc.gov/rr/mopic/avprot/DD_AMD.html]) cannot be generated via open source tools such as JHOVE ([http://www.loc.gov/rr/mopic/avprot/DD_AMD.html]) and FITS([http://code.google.com/p/fits/]) , and thus must be captured in some other manner		# Assessing which of our selected technical metadata fields (from MIX, for images: [http://www.loc.gov/standards/mix/] and AudioMD for audio: [http://www.loc.gov/rr/mopic/avprot/DD_AMD.html]) cannot be generated via open source tools such as JHOVE ([http://www.loc.gov/rr/mopic/avprot/DD_AMD.html]) and FITS([http://code.google.com/p/fits/]) , and thus must be captured in some other manner
	# Determining what technical metadata (such as version and type of format, to inform migration needs) needs to be readily available for file management (stored in a database for easy access, periodically exported as plain text for storage with the files)		# Determining what technical metadata (such as version and type of format, to inform migration needs) needs to be readily available for file management (stored in a database for easy access, periodically exported as plain text for storage with the files)
-	# Analyzing and rating PREMIS (Preservation Metadata: Implementation Strategies: [http://www.oclc.org/research/projects/pmwg/]) recommendations as to highest priority, middle priority, and lowest priority, to assist us in determining feasible methods for implementing the portion of these recommendations which are critical to our success	+	# Analyzing and rating PREMIS (Preservation Metadata: Implementation Strategies: [http://www.oclc.org/research/projects/pmwg/]) recommendations as to highest priority, middle priority, and lowest priority, to assist us in determining feasible methods for implementing the portion of these recommendations which are critical to our success. This latter has been completed and we agreed to minimal PREMIS compliance (spring 2011).

	*Jody DeRidder, Head of Digital Services, has developed a "map" [[Image:ArchiveMap.txt]] of the file structure, and created some level of text documentation or metadata about each level.		*Jody DeRidder, Head of Digital Services, has developed a "map" [[Image:ArchiveMap.txt]] of the file structure, and created some level of text documentation or metadata about each level.
Line 38:		Line 38:

	We continue to pursue use of LOCKSS (Lots of Copies Keeps Stuff Safe: [http://www.lockss.org/lockss/Home]) via the Alabama Digital Preservation Network (ADPNet: [http://www.adpn.org/]) as our primary method of "fallback" as this provides a method of handoff of content in the event our system fails completely.		We continue to pursue use of LOCKSS (Lots of Copies Keeps Stuff Safe: [http://www.lockss.org/lockss/Home]) via the Alabama Digital Preservation Network (ADPNet: [http://www.adpn.org/]) as our primary method of "fallback" as this provides a method of handoff of content in the event our system fails completely.
		+
		+	[[User:Jlderidder\|Jlderidder]]

Jlderidder at 20:46, 29 June 2011

2011-06-29T20:46:44Z

←Older revision		Revision as of 20:46, 29 June 2011
Line 26:		Line 26:
	# Analyzing and rating PREMIS (Preservation Metadata: Implementation Strategies: [http://www.oclc.org/research/projects/pmwg/]) recommendations as to highest priority, middle priority, and lowest priority, to assist us in determining feasible methods for implementing the portion of these recommendations which are critical to our success		# Analyzing and rating PREMIS (Preservation Metadata: Implementation Strategies: [http://www.oclc.org/research/projects/pmwg/]) recommendations as to highest priority, middle priority, and lowest priority, to assist us in determining feasible methods for implementing the portion of these recommendations which are critical to our success

-	*Jody DeRidder, Head of Digital Services, has developed a [[Image:ArchiveMap.txt ~~"map"~~]] of the file structure, and created some level of text documentation or metadata about each level.	+	*Jody DeRidder, Head of Digital Services, has developed a "map" [[Image:ArchiveMap.txt]] of the file structure, and created some level of text documentation or metadata about each level.

	*Digital Services personnel has selected appropriate open source tools for rendering current content, and will work with Jason Battles to determine the necessary open source operating system for support of these software tools.		*Digital Services personnel has selected appropriate open source tools for rendering current content, and will work with Jason Battles to determine the necessary open source operating system for support of these software tools.

Jlderidder at 20:45, 29 June 2011

2011-06-29T20:45:56Z

←Older revision		Revision as of 20:45, 29 June 2011
Line 26:		Line 26:
	# Analyzing and rating PREMIS (Preservation Metadata: Implementation Strategies: [http://www.oclc.org/research/projects/pmwg/]) recommendations as to highest priority, middle priority, and lowest priority, to assist us in determining feasible methods for implementing the portion of these recommendations which are critical to our success		# Analyzing and rating PREMIS (Preservation Metadata: Implementation Strategies: [http://www.oclc.org/research/projects/pmwg/]) recommendations as to highest priority, middle priority, and lowest priority, to assist us in determining feasible methods for implementing the portion of these recommendations which are critical to our success

-	*Jody DeRidder, Head of Digital Services, ~~will develop~~ a "map" of the file structure, and some level of documentation or metadata about each level ~~not yet described (this may require gathering information from Hoole Personnel, and may also involve consultations with the Metadata Unit)~~.	+	*Jody DeRidder, Head of Digital Services, has developed a [[Image:ArchiveMap.txt "map"]] of the file structure, and created some level of text documentation or metadata about each level.

-	*Digital Services personnel ~~will determine~~ appropriate open source tools for rendering current content, and will work with Jason Battles to determine the necessary open source operating system for support of these software tools.	+	*Digital Services personnel has selected appropriate open source tools for rendering current content, and will work with Jason Battles to determine the necessary open source operating system for support of these software tools.

	*Jason Battles will determine how we should periodically test the selected software and operating system for verification that they will indeed reconstruct access to our content.		*Jason Battles will determine how we should periodically test the selected software and operating system for verification that they will indeed reconstruct access to our content.

Jlderidder: /* Guiding Principles */

2009-09-09T22:44:40Z

Guiding Principles

←Older revision		Revision as of 22:44, 9 September 2009
Line 10:		Line 10:
	Since the costs of continued migration of content is very high, a method of mitigating that cost is to allow content to become obsolete, but to support sufficient metadata and contextual information to be able to resurrect full access and use at some future time (the '''"resurrection" principle'''). Preserving any type of digital information requires preserving the information's context so that it can be interpreted correctly.		Since the costs of continued migration of content is very high, a method of mitigating that cost is to allow content to become obsolete, but to support sufficient metadata and contextual information to be able to resurrect full access and use at some future time (the '''"resurrection" principle'''). Preserving any type of digital information requires preserving the information's context so that it can be interpreted correctly.

		+	Clifford Lynch pointed out at the iPres2008 Conference [http://www.bl.uk/ipres2008/] that we should preserve open source source code to document the standards we develop and to enable reconstruction of the content that we save.

-	Given that at the time of discovery, the file system itself may be obsolete, one potentially important task is storing inode information and information about the parameters of the file system (type of partition support needed, for example) at the top level in a plain text or XML manifest. Some information that should be included are then number and type of characters (Unicode? Latin 1?) allowed in file names, and other expectations for support. ~~Another suggestion was~~ to ~~ensure that each level~~ contains ~~a manifest describing~~ what ~~is at~~ the ~~level below it~~ and ~~how these contents relate~~. ~~Potentially~~, the ~~entire~~ file ~~system could be zipped up~~ and ~~included~~ with ~~a manifest~~ for ~~submission into~~ a ~~preservation storage~~ system ~~hosted elsewhere~~.	+	==Steps and Agreements==
		+
		+	Whatever we do must be feasible, reasonable, scalable, and specific to our needs at the University of Alabama. The following are the current steps being taken:
		+
		+	'''In support of the Resurrection and Relay Principles:'''
		+
		+	*Given that at the time of discovery, the file system itself may be obsolete, one potentially important task is storing inode information and information about the parameters of the file system (type of partition support needed, for example) at the top level in a plain text or XML manifest. Some information that should be included are then number and type of characters (Unicode? Latin 1?) allowed in file names, and other expectations for support. Jason Battles, Head of Web Services, will determine what information should be collected and stored for the University of Alabama Libraries digital archives.
		+
		+	*Janet Lee-Smeltzer, Head of Cataloging and Metadata Services, will engage the Metadata Unit in:
		+	# Creating a descriptive metadata file about the archive itself, to inform archivists of the future about what it contains, and its provenance
		+	# Assessing which of our selected technical metadata fields (from MIX, for images: [http://www.loc.gov/standards/mix/] and AudioMD for audio: [http://www.loc.gov/rr/mopic/avprot/DD_AMD.html]) cannot be generated via open source tools such as JHOVE ([http://www.loc.gov/rr/mopic/avprot/DD_AMD.html]) and FITS([http://code.google.com/p/fits/]) , and thus must be captured in some other manner
		+	# Determining what technical metadata (such as version and type of format, to inform migration needs) needs to be readily available for file management (stored in a database for easy access, periodically exported as plain text for storage with the files)
		+	# Analyzing and rating PREMIS (Preservation Metadata: Implementation Strategies: [http://www.oclc.org/research/projects/pmwg/]) recommendations as to highest priority, middle priority, and lowest priority, to assist us in determining feasible methods for implementing the portion of these recommendations which are critical to our success
		+
		+	*Jody DeRidder, Head of Digital Services, will develop a "map" of the file structure, and some level of documentation or metadata about each level not yet described (this may require gathering information from Hoole Personnel, and may also involve consultations with the Metadata Unit).
		+
		+	*Digital Services personnel will determine appropriate open source tools for rendering current content, and will work with Jason Battles to determine the necessary open source operating system for support of these software tools.
		+
		+	*Jason Battles will determine how we should periodically test the selected software and operating system for verification that they will indeed reconstruct access to our content.
		+
		+	*Tom Wilson proposed that we test the selected software and operating system yearly; we have agreed to this as a policy, to ensure that the stored software is the most appropriate. We also agreed to store it on a top level in a single location, with instructions as to how it should be used, and to what files it should be applied.
		+
		+
		+	'''In support of the Fallback Principle:'''
		+
		+	We continue to pursue use of LOCKSS (Lots of Copies Keeps Stuff Safe: [http://www.lockss.org/lockss/Home]) via the Alabama Digital Preservation Network (ADPNet: [http://www.adpn.org/]) as our primary method of "fallback" as this provides a method of handoff of content in the event our system fails completely.

Jlderidder: New page: ==Guiding Principles== Long term preservation can be considered a relay of content over time, a series of hand-offs occurring repeatedly at many levels: between types of media and storage...

2009-09-09T21:39:26Z

New page: ==Guiding Principles== Long term preservation can be considered a relay of content over time, a series of hand-offs occurring repeatedly at many levels: between types of media and storage...

New page

==Guiding Principles==

Long term preservation can be considered a relay of content over time, a series of hand-offs occurring repeatedly at many levels: between types of media and storage systems, object frameworks and software systems, different institutions and policy regimes, and different communities. As time passes, all links to the original creators and context will be severed, exacerbating the challenges.
The National Geospatial Digital Archive (NGDA: [http://www.ngda.org/] ) has identified three architectural design principles beyond OAIS ("Reference Model for an Open Archival System (OAIS)": [http://public.ccsds.org/publications/archive/650x0b1.pdf]) which are necessary to preserve content over time: the "relay" principle, the "fallback" principle, and the "resurrection" principle.

The '''"relay" principle''' states that a preservation system should support its own migration.

In the event that the system itself is no longer functional, then a preservation system should support some form of hand-off of its content (this is the '''"fallback" principle''').

Since the costs of continued migration of content is very high, a method of mitigating that cost is to allow content to become obsolete, but to support sufficient metadata and contextual information to be able to resurrect full access and use at some future time (the '''"resurrection" principle'''). Preserving any type of digital information requires preserving the information's context so that it can be interpreted correctly.

Given that at the time of discovery, the file system itself may be obsolete, one potentially important task is storing inode information and information about the parameters of the file system (type of partition support needed, for example) at the top level in a plain text or XML manifest. Some information that should be included are then number and type of characters (Unicode? Latin 1?) allowed in file names, and other expectations for support. Another suggestion was to ensure that each level contains a manifest describing what is at the level below it and how these contents relate. Potentially, the entire file system could be zipped up and included with a manifest for submission into a preservation storage system hosted elsewhere.

←Older revision		Revision as of 15:31, 14 December 2012
Line 18:		Line 18:
	'''In support of the Resurrection and Relay Principles:'''		'''In support of the Resurrection and Relay Principles:'''

-	*Given that at the time of discovery, the file system itself may be obsolete, one potentially important task is storing inode information and information about the parameters of the file system (type of partition support needed, for example) at the top level in a plain text or XML manifest. Some information that should be included are then number and type of characters (Unicode? Latin 1?) allowed in file names, and other expectations for support. ~~Jason Battles,~~ Head of Web Services~~, will determine~~ what information should be collected and stored for the University of Alabama Libraries digital archives.	+	*Given that at the time of discovery, the file system itself may be obsolete, one potentially important task is storing inode information and information about the parameters of the file system (type of partition support needed, for example) at the top level in a plain text or XML manifest. Some information that should be included are then number and type of characters (Unicode? Latin 1?) allowed in file names, and other expectations for support. Our Head of Web Services is responsible for determining what system information should be collected and stored for the University of Alabama Libraries digital archives.

-	*~~Janet Lee-Smeltzer,~~ Head of Cataloging and Metadata Services~~, will engage~~ the Metadata Unit in:	+	* Our Head of Cataloging and Metadata Services is responsible for ensuring that the Metadata Unit:
-	# ~~Creating~~ a descriptive metadata file about the archive itself, to inform archivists of the future about what it contains, and its provenance	+	# Creates and maintains a descriptive metadata file about the archive itself, to inform archivists of the future about what it contains, and its provenance
-	# ~~Assessing~~ which of our selected technical metadata fields (from MIX, for images: [http://www.loc.gov/standards/mix/] and AudioMD for audio: [http://www.loc.gov/rr/mopic/avprot/DD_AMD.html]) cannot be generated via open source tools such as JHOVE ([http://www.loc.gov/rr/mopic/avprot/DD_AMD.html]) and FITS([http://code.google.com/p/fits/]) , and thus must be captured in some other manner	+	# Assesses which of our selected technical metadata fields (from MIX, for images: [http://www.loc.gov/standards/mix/] and AudioMD for audio: [http://www.loc.gov/rr/mopic/avprot/DD_AMD.html]) cannot be generated via open source tools such as JHOVE ([http://www.loc.gov/rr/mopic/avprot/DD_AMD.html]) and FITS([http://code.google.com/p/fits/]) , and thus must be captured in some other manner
-	# ~~Determining~~ what technical metadata (such as version and type of format, to inform migration needs) needs to be readily available for file management (stored in a database for easy access, periodically exported as plain text for storage with the files)	+	# Determines what technical metadata (such as version and type of format, to inform migration needs) needs to be readily available for file management (stored in a database for easy access, periodically exported as plain text for storage with the files)
-	# ~~Analyzing~~ and ~~rating~~ PREMIS (Preservation Metadata: Implementation Strategies: [http://www.oclc.org/research/projects/pmwg/]) recommendations as to highest priority, middle priority, and lowest priority, to assist us in determining feasible methods for implementing the portion of these recommendations which are critical to our success. This latter has been completed and we agreed to minimal PREMIS compliance (spring 2011).	+	# Analyzes and rates PREMIS (Preservation Metadata: Implementation Strategies: [http://www.oclc.org/research/projects/pmwg/]) recommendations as to highest priority, middle priority, and lowest priority, to assist us in determining feasible methods for implementing the portion of these recommendations which are critical to our success. This latter has been completed and we agreed to minimal PREMIS compliance (spring 2011).

-	*~~Jody DeRidder,~~ Head of Digital Services, has developed a "map" [[Image:ArchiveMap.txt]] of the file structure, and created some level of text documentation or metadata about each level.	+	*Our Head of Digital Services has developed a "map" [[Image:ArchiveMap.txt]] of the file structure, and created some level of text documentation or metadata about each level.

	*Digital Services personnel has selected appropriate open source tools for rendering current content, and will work with Jason Battles to determine the necessary open source operating system for support of these software tools.		*Digital Services personnel has selected appropriate open source tools for rendering current content, and will work with Jason Battles to determine the necessary open source operating system for support of these software tools.

-	*~~Jason Battles will determine~~ how we should periodically test the selected software and operating system for verification that they will indeed reconstruct access to our content.	+	*Our Head of Web Services is also responsible for determining how we should periodically test the selected software and operating system for verification that they will indeed reconstruct access to our content.

-	*~~Tom Wilson~~ proposed that we test the selected software and operating system yearly; we have agreed to this as a policy, to ensure that the stored software is the most appropriate. We also agreed to store it on a top level in a single location, with instructions as to how it should be used, and to what files it should be applied.	+	*Our Associate Dean of Library Technology proposed that we test the selected software and operating system yearly; we have agreed to this as a policy, to ensure that the stored software is the most appropriate. We also agreed to store it on a top level in a single location, with instructions as to how it should be used, and to what files it should be applied.


Line 40:		Line 40:

	[[User:Jlderidder\|Jlderidder]]		[[User:Jlderidder\|Jlderidder]]
		+	09:31, 14 December 2012 (CST)