File Naming and Linking for LOCKSS - Revision history

Jlderidder at 14:13, 30 September 2011

Jlderidder — Fri, 30 Sep 2011 14:13:31 GMT

←Older revision		Revision as of 14:13, 30 September 2011
Line 5:		Line 5:
	Hence, all metadata and documentation files that we store in LOCKSS will be assigned a version number, and that copy is what will be linked. However, we will only store the oldest and most recent versions of metadata.		Hence, all metadata and documentation files that we store in LOCKSS will be assigned a version number, and that copy is what will be linked. However, we will only store the oldest and most recent versions of metadata.

-	Thus, the first version of u0003_0000252_0000002.mods.xml will have a copy made and named u0003_0000252_0000002.mods.v1.xml which will be stored in the same directory, and it will be '''this''' file which is linked in LOCKSS manifests.

-	~~When~~ the ~~next~~ version of ~~the~~ u0003_0000252_0000002.mods.xml ~~is created, it overwrites the~~ u0003_0000252_0000002.mods.xml in the ~~storage~~ directory, ~~AND is copied to u0003_0000252_0000002.mods.v2.xml, which~~ will be ~~added to the~~ LOCKSS ~~manifest~~.	+	Thus, the '''first version''' of u0003_0000252_0000002.mods.xml will have a copy made and named u0003_0000252_0000002.mods.v1.xml which will be stored in the same directory, and it will be '''this''' file which is linked in LOCKSS manifests.

-	Following versions of u0003_0000252_0000002.mods.xml also overwrite the u0003_0000252_0000002.mods.xml in the storage directory, AND	+
		+	When '''the next version''' of the u0003_0000252_0000002.mods.xml is created, it overwrites the u0003_0000252_0000002.mods.xml in the storage directory, AND is copied to u0003_0000252_0000002.mods.v2.xml, which will be added to the LOCKSS manifest.
		+
		+
		+	'''Following versions''' of u0003_0000252_0000002.mods.xml also overwrite the u0003_0000252_0000002.mods.xml in the storage directory, AND
	overwrite u0003_0000252_0000002.mods.v2.xml (after backing it up if in LOCKSS). Since this is already linked into the LOCKSS		overwrite u0003_0000252_0000002.mods.v2.xml (after backing it up if in LOCKSS). Since this is already linked into the LOCKSS
	manifest, it is not linked again. The backup copies (if the collection has been harvested by LOCKSS partners)		manifest, it is not linked again. The backup copies (if the collection has been harvested by LOCKSS partners)
	have the suffix "_LOCKSS_yyyy-mm-dd" so we can measure the size of our possible		have the suffix "_LOCKSS_yyyy-mm-dd" so we can measure the size of our possible
-	LOCKSS content. In the future, we hope to modify LOCKSS storage to delete all but the most recent .v2.mods.xml and .v2.ead.xml files.	+	LOCKSS content. ''In the future, we hope to modify LOCKSS storage to delete all but the most recent .v2.mods.xml and .v2.ead.xml files.''

-	In this way, the delivery software which draws from our storage content will always pick up the most recent version of the metadata, and LOCKSS manifests themselves will not be impacted by our metadata upgrades.	+	'''In this way, the delivery software which draws from our storage content will always pick up the most recent version of the metadata, and LOCKSS manifests themselves will not be impacted by our metadata upgrades.'''

-	~~Currently~~, we have selected this content for long term storage AND linking into LOCKSS manifests:	+
		+	'''As of September 2011, we have selected this content for long term storage AND linking into LOCKSS manifests:'''
	#archival tiffs		#archival tiffs
	#archival wav files		#archival wav files
Line 47:		Line 51:

	Each Manifest has the following statement at the bottom: "LOCKSS system has permission to collect, preserve, and serve this Archival Unit"		Each Manifest has the following statement at the bottom: "LOCKSS system has permission to collect, preserve, and serve this Archival Unit"
		+
		+	[[User:Jlderidder\|Jlderidder]]

Jlderidder at 14:11, 30 September 2011

Jlderidder — Fri, 30 Sep 2011 14:11:41 GMT

←Older revision		Revision as of 14:11, 30 September 2011
Line 3:		Line 3:
	However, metadata regularly changes, and we would like to keep our '''current''' version of the metadata as the same filename from version to version.		However, metadata regularly changes, and we would like to keep our '''current''' version of the metadata as the same filename from version to version.

-	Hence, all metadata and documentation files that we store in LOCKSS will be assigned a version number, and that copy is what will be linked.	+	Hence, all metadata and documentation files that we store in LOCKSS will be assigned a version number, and that copy is what will be linked. However, we will only store the oldest and most recent versions of metadata.

-	Thus, the first version of u0003_0000252_0000002.~~mets~~.xml will have a copy made and named u0003_0000252_0000002.~~mets~~.v1.xml which will be stored in the same directory, and it will be '''this''' file which is linked in LOCKSS manifests.	+	Thus, the first version of u0003_0000252_0000002.mods.xml will have a copy made and named u0003_0000252_0000002.mods.v1.xml which will be stored in the same directory, and it will be '''this''' file which is linked in LOCKSS manifests.

-	When the next version of the u0003_0000252_0000002.~~mets~~.xml is created, it ~~will overwrite~~ the u0003_0000252_0000002.~~mets~~.xml in the storage directory, AND be copied to u0003_0000252_0000002.~~mets~~.v2.xml, which will be added to the LOCKSS manifest.	+	When the next version of the u0003_0000252_0000002.mods.xml is created, it overwrites the u0003_0000252_0000002.mods.xml in the storage directory, AND is copied to u0003_0000252_0000002.mods.v2.xml, which will be added to the LOCKSS manifest.

-	In this way, the delivery software which draws from our storage content will always pick up the most recent version of the metadata, and LOCKSS will not be impacted by our metadata upgrades.	+	Following versions of u0003_0000252_0000002.mods.xml also overwrite the u0003_0000252_0000002.mods.xml in the storage directory, AND
		+	overwrite u0003_0000252_0000002.mods.v2.xml (after backing it up if in LOCKSS). Since this is already linked into the LOCKSS
		+	manifest, it is not linked again. The backup copies (if the collection has been harvested by LOCKSS partners)
		+	have the suffix "_LOCKSS_yyyy-mm-dd" so we can measure the size of our possible
		+	LOCKSS content. In the future, we hope to modify LOCKSS storage to delete all but the most recent .v2.mods.xml and .v2.ead.xml files.
		+
		+	In this way, the delivery software which draws from our storage content will always pick up the most recent version of the metadata, and LOCKSS manifests themselves will not be impacted by our metadata upgrades.

	Currently, we have selected this content for long term storage AND linking into LOCKSS manifests:		Currently, we have selected this content for long term storage AND linking into LOCKSS manifests:
Line 19:		Line 25:
	#collection information xml		#collection information xml
	#a png icon for each collection		#a png icon for each collection
		+	#MODS xml

	Other files may exist in the directories which are important to us, but which are not necessary for inclusion in LOCKSS. Those files must be in archival formats.		Other files may exist in the directories which are important to us, but which are not necessary for inclusion in LOCKSS. Those files must be in archival formats.

Jlderidder at 20:06, 15 July 2009

Jlderidder — Wed, 15 Jul 2009 20:06:39 GMT

←Older revision		Revision as of 20:06, 15 July 2009
Line 33:		Line 33:
	#Administrative Information (contents of Documentation directory),		#Administrative Information (contents of Documentation directory),
	#Collection Level Metadata (Contents of collection level Metadata directory),		#Collection Level Metadata (Contents of collection level Metadata directory),
-	#Metadata (for each item) ~~and~~	+	#Metadata (for each item)
		+	#Transcripts (if available)
	#Content (archival files).		#Content (archival files).

Jlderidder: New page: Once content is harvested into LOCKSS, that content should not change. However, metadata regularly changes, and we would like to keep our '''current''' version of the metadata as the same...

Jlderidder — Thu, 25 Jun 2009 20:56:56 GMT

New page: Once content is harvested into LOCKSS, that content should not change. However, metadata regularly changes, and we would like to keep our '''current''' version of the metadata as the same...

New page

Once content is harvested into LOCKSS, that content should not change.

However, metadata regularly changes, and we would like to keep our '''current''' version of the metadata as the same filename from version to version.

Hence, all metadata and documentation files that we store in LOCKSS will be assigned a version number, and that copy is what will be linked.

Thus, the first version of u0003_0000252_0000002.mets.xml will have a copy made and named u0003_0000252_0000002.mets.v1.xml which will be stored in the same directory, and it will be '''this''' file which is linked in LOCKSS manifests.

When the next version of the u0003_0000252_0000002.mets.xml is created, it will overwrite the u0003_0000252_0000002.mets.xml in the storage directory, AND be copied to u0003_0000252_0000002.mets.v2.xml, which will be added to the LOCKSS manifest.

In this way, the delivery software which draws from our storage content will always pick up the most recent version of the metadata, and LOCKSS will not be impacted by our metadata upgrades.

Currently, we have selected this content for long term storage AND linking into LOCKSS manifests:
#archival tiffs
#archival wav files
#METS xml containing Qualified Dublin Core
#tab-delimited text files containing metadata spreadsheets for entire collections
#EAD xml
#collection information xml
#a png icon for each collection

Other files may exist in the directories which are important to us, but which are not necessary for inclusion in LOCKSS. Those files must be in archival formats.

Each link specifies what is linked. For example:
<a href="http://libapp.lib.ua-net.ua.edu/lockss/u0003/0000252/Documentation/Manifest.html">Septimus D. Cabaniss Papers u0003_0000252 Manifest.html</a>

Our Manifests are named Manifest.html, and one exists in each Documentation directory on each level, linking to any levels beneath it which offer content for harvesting.

Each Manifest is divided into sections which use lists to provide access to the links:
#Administrative Information (contents of Documentation directory),
#Collection Level Metadata (Contents of collection level Metadata directory),
#Metadata (for each item) and
#Content (archival files).

Each Manifest states the collection name (or level name) and number, for example: "Septimus D. Cabaniss Papers u0003_0000252 LOCKSS Manifest Page" or "University of Alabama Hoole Special Collections Manucripts u0003 Manifest Page".

Each Manifest has the following statement at the bottom: "LOCKSS system has permission to collect, preserve, and serve this Archival Unit"