Archive Repository

The 700 or so archives held by LHC are really core to our mission, and therefore the maintenance of a world-class digital archival repository is a major priority. There are several standards which govern this effort. First, the archives must be compliant with the EAD standard (Encoded Archival Description) which has been put forth by the library of congress (LOC) at http://www.loc.gov/ead/ and the Society of American Archivists at http://www.archivists.org/saagroups/ead/

Once the archival description is in EAD format, it can be exposed to union catalogs which make LHC finding aids visible to researchers around the globe. The problem is that EAD is quite complex, and so authoring the archival description such that it can be rendered in the EAD XML format requires some specialized tools.

One such tool, named Archon, has been developed at the University of Illinois http://archon.org/ This is a web-based, open-source system which uses the LAMP technology stack. LHC plans to use Archon to create the finding aids and put them into the EAD format.

But The Archon system does not have OAI-PMH compliance, nor does it have a consistent user interface with our content system, or user access controls. For this reason, we can take the output of Archon, once a finding aid has been developed, and put it into Drupal, where it shares the same UI (user interface) and database access as the rest of our repository. For LHC insiders and authorized researchers, we can give access to the Archon system directly, which will have enhanced search facilities for the archival system.

This approach involves some redundancy, as records for the archive must exist both in Drupal and in Archon, but there is no easier way to get the EAD format we need. If we were to give up on that requirement then we could create plain-text finding aids and store them in Drupal alone. However, Archon does impose discipline in the creation of finding aids, restriction to authorized vocabularies, etc. and doesn't impose too much extra work creating content records in Drupal, so this seems to be the best approach.