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]]

Latest revision as of 08:13, 30 September 2011

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. 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.

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.

As of September 2011, we have selected this content for long term storage AND linking into LOCKSS manifests: