Tracking for the long term
We're developing a tracking database for management of content over time. Recognizing that this is still software-dependent, and that relational databases are inherently unstable, the plan is to periodically print reports from the database and store these as flat files in the top levels of the storage system, as a form of manifest.
The primary location of InfoTrack is on libcontent1.lib.ua.edu; any changes made to it should be there, for it is then copied to content.lib.ua.edu for access and delivery of collection information by PHP scripts. Since we do not intend to continue with our CONTENTdm delivery system on content.lib.ua.edu, and that server needs rebuilding, that is NOT the primary site for this database.
The InfoTrack database
Currently has seven tables:
This table contains information about each collection sufficient for a PHP script to be able to dynamically deliver an alphabetized list of current online collections, descriptions of them, icons, links to the content (and if available, the Manuscript number associated, and the link to that online). Most of this information comes from the Collection_Information file created by Digital Services personnel when they begin to digitize a collection, drawing information from the spreadsheets filled out by archivists. This information is uploaded by the collToDbase script described in step 10 of Moving_Content_To_Long-Term_Storage. That script also adds the expected canned link for retrieving content, and specifies if the collection is online yet. Other information that may at some point be stored in this table includes the long-term storage location of the content, the date it went online, query terms and query fields used to retrieve the content.
This table is designed to capture the type of format an file is in, a URL to information on that format, the quality of the capture, and the version of the format. For example, a TIFF version 6.0 file captured at 600 dpi would have a URL entered from the Unified Digital Format Registry ([] similar to this one now available via the PRONOM Digital Format Registry: [].
By maintaining a record of the current format, version, and quality of each file, in a database, we can easily identify and locate all files in need of migration or emulation in the face of approaching obsolescence.
Similarly, this table is designed to capture the current type, version, schema of both descriptive and technical metadata for an item, and also the location of any existing data dictionaries which may help decipher how particular fields were used. A query on this table should be able to tell us what metadata needs to be revamped to meet the current pressing need or software change.
This table is a temporary holding place for information about how files are related, until it can be captured in a METS file. This table probably is not long for this world. Currently, it is designed to hold the parent ID number, the collection ID number, the item's ID number, and the number of child files this item has.
As we have migrated legacy content to our standardized File_naming_schemes, and in and out of CONTENTdm (which assigns its own identifiers, database numbers, and OAI identifiers), we've struggled to keep track of all the names associated with each item. This is the centralized table in which that should happen. Again, this table is in transition, and it may lose some CONTENTdm identifiers after we've left that system, and will probably gain other identifier types over time.
This table was created to support persistent identifiers. It's a lookup table to provide redirects. Each item for which we would like to provide this support will be assigned a number. Retrieval of that item will be by using a URL of the form: http://purl.lib.ua.edu/3234 where the number following the last forward slash is the number of the item. The actual url is stored in this table, along with the assigned number, and possibly an OAI identifier, an original identifier, but certainly a history of any changes. This table is accessed by the script redirect.pl which lives in the cgi-bin of libcontent1.lib.ua.edu. A URL rewrite and a virtual host configuration, along with the DNS registration of purl.lib.ua.edu, were the only other support necessary for this to work. Whenever a file must be moved, the database is updated, and the persistent URL continues to work. In this fashion, we may enter URLs into metadata, webpages, online catalogs, etc., and never have to change them.
As we are moving away from CONTENTdm, the cdm_location table is not likely to survive much longer; it was designed to identify the database number, the file identifier number, the CONTENTdm container ("collection") and the CONTENTdm reference URL, for each item stored in that software.