59
Archival Management Software
15
asked questions, and user training. In some cases, help is
included in annual maintenance fees, but in others it en-
-
tails additional costs. Open source projects may seem to be
weaker than commercial projects with regard to user
support. As one archivist using an open source system
commented, “There’s no help desk.” However, lively
communities often form around open source projects and
provide support to new users or those experiencing prob-
lems. With Archon, CollectiveAccess, and Archivists’
Toolkit, archivists noted how responsive the developers
are to questions. In addition, support for open source
software may be available from consultancies or even the
developers themselves. For example, the business plan for
ICA AToM includes a provision for “charging a commis-
sion for brokering ICA-AtoM technical services between
recommended third-party contractors and institutions
seeking assistance with ICA-AtoM installation, hosting,
customization, new feature development, etc.” To evaluate
user support, talk to users of different software packages.
• Support for archival standards
To facilitate interoperability and adherence to best prac-
tices, archives will want to select software that meets ar-
chival standards such as EAD, DACS, and MARC, as well
as emerging standards such as EAC. Some archival
systems, such as ICA-AToM, focus more on international
(ICA) standards rather than on U.S. standards. In the case
ase
of archival software developed in Europe, Prom et al. warn
that “such tools use a much more rigorous system of
classification and provenance than do US repositories”
(Prom et al. 2007, 159). However, even many non-U.S.
.
applications support crosswalking between standards and
include EAD support.
• Web-based versus desktop client
ent
.
Some archival management software (such as Archon,
CollectiveAccess, and ICA-AToM) is entirely Web based,
d,
while other such software requires a desktop client (typi-
-
cally a PC) and connect to a database backend. Web-based
software can be more intuitive for some users and enables
distributed cataloging, since anyone with Web access can
contribute records. With systems such as Archon,
information can be published to the Web as soon as it is
entered. However, some archives worry about the security
and reliability of an entirely Web-based system; one archi-
-
vist noted her colleagues’ reluctance to “put all of our eggs
in one basket.” If the Internet connection goes down, work
stops (which is also true of networked client/server
software). A client-based interface may offer greater con-
-
trol over data, but institutions may need to pay a fee for
52
Lisa Spiro
16
each computer on which the software is installed. Licens-
-
ing models vary, however, so this is not always the case.
• Support for publishing finding aids online versus
generating EAD for export
Many archives face difficulty not only in creating EAD
files but also in publishing them online. As one archivist
remarked, “There’s been a big hole—people have been
producing EAD for 10 years, but it’s still kind of difficult.”
Some archival management systems address this problem
by enabling archives to make available their finding aids
on the Web. Indeed, a primary reason that Archon was
developed was to facilitate publication of archival
information online. Once an archivist enters information
into Archon, it is automatically searchable and
discoverable by Google (although archives can choose to
defer publication of records until they have been ap-
proved). Likewise, many commercial systems offer sup-
port for online access to their collections, sometimes
through the purchase of an additional module. However,
some archives already have a mechanism for publishing
their finding aids on the Web, so they may prefer software
that enables them to easily export finding aids that they
can then import into their existing Web-publication sys-
-
tem. Since most browsers now provide support for XML,
archives could simply upload their EAD files to a Web
server, include a call-out to an XSLT stylesheet at the top of
each file for the purposes of presentation, and display their
finding aids without too much effort. Projects such as the
EAD Cookbook have made stylesheets freely available.
Although this simple approach does not offer so-
phisticated searching and other features, it enables ar-
chives to publish their finding aids online at minimal cost.
If archival management software does enable publishing
archival collections online, archives should consider the
quality and customizability of the end-user interface. Does
it provide search and browse functions? Can users run
advanced searches? Does it offer additional features, such
as stored searches? Is the design clean and simple to
navigate? Can it be easily customized to reflect the unique
identity of the archive? Does the interface meet accessibil-
ity standards? Can it be translated into other languages?
• Support for linking to digital objects
In addition to providing access to archival collections, ar-
chives may wish to make available digital surrogates of
items, such as images, texts, audio files, or video. Many
archival management systems offer a “digital library” or
“online exhibit” function to provide Web-based access to
items in their collections. In evaluating these features, ar-
50
Archival Management Software
17
chives should consider what kind of media and metadata
formats they support as well as how media are presented.
For instance, CollectiveAccess has rich features for media
support, including the automatic generation of MP3s upon
loading an audio file to the server, an image viewer with
pan and zoom, and the ability to mark time codes within
video files. However, some archives may want to use a
separate digital asset management system (DAM), such as
ContentDM, DSpace, or Fedora, to provide online access to
their collections, since they are using these robust systems
for other digital collections. These institutions will want an
easy way to batch export relevant metadata from their
archival management system or, even better, a way to plug
in their archival management system to their DAM. (ICA-
AToM plans to use a plug-in architecture for exposing the
application to Web services or allowing it to interface with
other Web services, such as DSpace or Fedora.)
• Support for collection management
Some systems offer robust support for managing archival
collections, including appraisals, locations, condition and
conservation, and rights and restrictions. Some even allow
users to create deeds of gift and location labels, track usage
statistics, and manage requests for materials and reference
help. Others focus more on archival description than on
collection management. Many do both. Archives should
determine what features are most essential to them, while
noting that new versions of software often add features
that they may desire.
• Reports, statistics, and project management
Some software can enable institutions to run reports to, for
example, track unprocessed collections or determine what
is stored in a particular location. How easy is it to create
and print out such reports? Through archival management
software, organizations may also be able to track statistics
such as the size of various collections, how many linear
feet have been processed or deaccessioned over a year, and
the most frequently requested collections.
13
Such statistics
can help archives determine how to set processing
priorities and can be valuable in reporting to organizations
such as ARL. Indeed, some software even allows
institutions to mark accessions that are high priority for
processing, helping them manage hidden collections.
• Reliability and maturity
13
The University of Michigan is developing archival metrics:
http://www.si.umich.edu/ArchivalMetrics/
53
Lisa Spiro
18
Some archives are shying away from software that is still
in development such as Archivists’ Toolkit and Archon
because “there are still bug reports.” Users did report that
there were some bugs or missing features for both tools, as
well as for commercial systems. However, they also said
that their error reports were taken seriously and that the
development teams are responsive to user questions and
suggestions. In the contemporary computing environment,
software is continually evolving; witness the “permanent
beta” status of Web 2.0 tools such as Google Documents. It
is possible for software to be too mature, built using out-of-
-
date technologies or approaches. On the other hand, some
software never makes it out of beta or may not go in the
direction anticipated, so institutions may lose time and
resources if they adopt untested software.
7. Types of Software
In 2005, Katherine Wisser reported on an EAD Tools Survey
that revealed the diversity of ways in which archives created
finding aids and the difficulty that smaller institutions in par-
ticular had in authoring and publishing EAD. Wisser divided
EAD tools into four categories: authoring, publishing, discov-
ery (search tools), and knowledge (best practice guides). One
of the most used tools at the time was the EAD Cookbook,
which provides a set of templates, stylesheets, and guidelines
for creating finding aids. Wisser found a disparity in the kinds
of tools institutions used: archivists at smaller archives tended
to rely upon the EAD Cookbook, while those at larger
institutions often developed their own solutions. Some insti-
tutions were willing to share those solutions, with the caveat
that they reflected local practices.
More recently, open source archival management systems
such as Archon and AT and commercial solutions such as
Cuadra STAR and MINISIS have offered other methods for
creating archival description. The promise of such systems is
that archivists no longer have to hand-code EAD, but can cre-
-
ate it through entering information into database fields. Rather
than keeping archival data in multiple systems, archivists can
manage, search, and manipulate data through a single
interface. However, such systems can also enforce a rigor that
may challenge existing workflows, and importing legacy data
into them can be difficult.
Below I briefly describe a range of archival software packages
es
that support exporting or publishing EAD and MARC or are
likely to do so soon. Since the focus of this report is archival
management systems, only brief descriptions of more spe-
cialized EAD authoring and publishing tools are provided,
and no information is offered about digital asset management
systems, institutional repository software, integrated library
57
Archival Management Software
19
systems, or digital collections software.
14
Appendix 2 summa-
rizes the features of archival management systems in brief,
while Appendix 3 offers a detailed summary of these features.
es.
Appendix 4 presents summaries of my interviews with current
users of several leading archival management systems.
1. EAD Authoring
According to a 2006 study by Chris Prom, archivists use a
variety of tools to create descriptive records, favoring “simple”
tools: “Eighty-two percent use word processors; 55%, library
catalog software; 34% custom databases; 31% text or HTML
editors; 22% XML editors, and 14% digital library software”
(Prom 2008, 21). Archives using XML editors typically have a
a
larger backlog (58% of the collection) than those using word
processors (37%), leading Prom to suggest that “[a]t least some
of our backlog problems seem attributable to the adoption of
complex tools and methodologies” (2008, 22). However, these
e
institutions may have had larger backlogs to begin with. Prom
found a low adoption rate of MARC and EAD—access to only
an average of 37 percent of collections is provided through
MARC, 13 percent through EAD (2008, 23-24).
.
Often archives use a mix of methods to create finding aids. For
instance, UC Berkeley converted legacy finding aids to EAD
through a multifaceted approach, entering basic descriptive
information into Web templates
(http://www.cdlib.org/inside/projects/oac/toolkit/template
s/
) and employing WordPerfect to create the initial hierarchy
for the collection. It then converted the WordPerfect files to
EAD using macros and Perl scripts
(http://www.cdlib.org/inside/projects/oac/toolkit/
). XML
editors were primarily used as “reference tool[s],” since “[i]t is
far faster to programmatically convert text to EAD in broad
strokes than to apply the copy and paste method required
when using these editors” (Digital Publishing Group, UC
Berkeley Library, n.d.). Likewise, the University of Chicago
uses Web forms to create the front matter for finding aids;
archivists write inventories using Word, and then a script is
run to generate EAD. Post-processing is done using an XML
editor such as Oxygen. According to archivists at the
University of Chicago, such an approach “provides the archi-
vist with a lot of flexibility.”
Among the particular technologies used to create EAD are the
following:
A. XML/text editors
XML editors enable archivists to see the entire hierarchy of a
14
For more information about metadata description tools, see Smith-
Yoshimura and Cellentani 2007.
80
Lisa Spiro
20
finding aid and engage in the intellectual activity of marking
up an archival collection.
15
As one archivist noted, “The act of
writing a finding aid is something where you need to be able
to view contents as you write series description. Creating
finding aids is not data entry, but an intelligent process. I think
that encoding EAD helps you to write finding aids, to
understand the texture of a document.” However, relying
solely on XML editors to generate finding aids can be ineffi-
cient. According to “informal studies” at the University of
Illinois-Urbana Champaign, “a skilled worker took 20 hours to
encode a 100-page finding aid, using standard XML markup
tools, on top of the time needed to actually write the collection
description and develop a general box listing of its content”
(Prom et al. 2007, 159).
XML and customizable text editors include:
1.
XMetaL:
:
16
Extensible, collaborative commercial soft-
ware for authoring XML. To provide a more user-
friendly interface for creating and editing finding aids,
Yale University has developed a finding aids authoring
tool layered over XMetaL. Yale’s FACT tool customizes
XMetaL to provide a “word processing” view of
finding aids for staff who didn’t want to work with the
XML elements. Archives such as the University of
Minnesota have developed tips for using XMetaL to
author EAD.
17
2.
Oxygen:
18
Easy-to-use, commercial “cross platform
form
XML editor providing the tools for XML authoring,
XML conversion, XML Schema, DTD, Relax NG and
Schematron development, XPath, XSLT,” etc. Several
archives and consortia, including Northwest Digital
Archives, provide documentation for using Oxygen to
create EAD.
19
3.
NoteTab: A free or inexpensive text editor. Several
al
projects, including NC Echo,
20
Virginia Heritage,
21
and
the EAD Cookbook,
22
have created clipbook libraries
for NoteTab that facilitate the creation of EAD. Ac-
cording to a recent report by the Florida Center for Li-
brary Automation (FCLA), “the existing, customizable
NoteTab templates maintained by FCLA have been
very helpful for many organizations wishing to create
15
See ArchivesHub’s Data Creation Web page for more on XML editors:
http://www.archiveshub.ac.uk/arch/dc.shtml
16
http://na.justsystems.com/content.php?page=xmetal
17
https://wiki.lib.umn.edu/Staff/FindingAidsInEAD
18
http://www.oxygenxml.com/
19
See http://orbiscascade.org/index/northwest-digital-archives-tools
ools
20
See http://www.ncecho.org/ncead/tools/tools_home.htm
21
See http://www.lib.virginia.edu/small/vhp/admin.html
22
See http://www.archivists.org/saagroups/ead/ead2002cookbook.html
54
Archival Management Software
21
EAD-encoded finding aids” (Florida Center for Library
Automation 2008).
4.
EAD Cookbook: The EAD Cookbook aims to make it
easier for archives to create finding aids by providing
authoring tools for Oxygen, XMetaL, and NoteTab. In
addition, it offers a set of stylesheets for transforming
XML finding aids into HTML and detailed guidance on
creating and publishing EAD finding aids.
5.
MEX (Midosa-Editor in XML-Standards): Describes
cribes
itself as “a set of tools for everyday description work in
archival institutions including the production of online
finding aids with digitized images from the archival
records.”
23
An open source application developed by
the Federal Archives of Germany with support from
The Andrew W. Mellon Foundation, MEX enables
archivists to create, import, and edit EAD finding aids;
attach digital objects; examine an entire XML file or a
single element; create online presentations of finding
aids; and provide both search and structured
browsing. It is a plug-in to Eclipse, an open source Java
development platform.
B. Word processing templates
A number of archives use or have used word processing
software such as Microsoft Word, WordPerfect, or Open Office
to create preliminary finding aids. In some cases, organi-
zations have created templates that make it easy to enter
standard archival information. Often they also use macros or
scripts to aid in the conversion to EAD. For example, Yale has
experimented with Open Office as tool for EAD creation (Yale
University Library 2003), the Bentley Library at the University
of Michigan has developed macros to convert Word files to
EAD XML (Bentley Historical Library, n. d.), and the Utah
State Archives used WordPerfect to create container lists (Utah
State Archives 2002). Similarly, the Utah State Archives
produces container lists using Excel and MailMerge (Perkes
2008).
C. Forms
By using forms to produce finding aids, archives can speed
their creation and ensure greater consistency. Forms can be
Web based or desktop based:
• Berkeley Web Template: CGI script is a customizable cgi-
i-
driven Web application “that generates a user-defined
HTML form template and then generates markup using
23
See http://mextoolset.wiki.sourceforge.net/ and
http://www.bundesarchiv.de/daofind/en/
62
Lisa Spiro
22
the values filled in by users. … Output may be in the form
of METS, TEI, EAD, XML or SGML, even HTML or PDF”
(University of California, Berkeley 2005).
• Online Archive of California: Makes available Web forms
ms
“for generating collection- through series-/subseries-level
evel
finding aids that are compliant with the OAC BPG EAD
and EAD Version 2002. Encoders cut and paste segments
of their non-EAD finding aids into the form. The form is
then converted to a text file and saved as a XML EAD
file.”
24
• ArchivesHub: Provides a Web form for generating EAD
AD
2002.
25
• EAD XForms: Justin Banks’s EAD templates allow users to
to
enter archival information into a form. The templates were
built using Altova’s StyleVision2006 and require an XML
editor such as Altova Authentic2006 or Altova XMLSpy to
implement.
26
• X-EAD: The University of Utah is developing form-based
based
desktop software for authoring and editing EAD.
27
D. EAD Validation
By validating EAD files, archives can ensure their adherence
to standards and facilitate participation in union catalogs and
regional repositories. Several online validation services are
available, including the following:
• Florida Center for Library Automation’s Encoded Archi-
-
val Description Validator and XSL Transformer: A Web
page that was “created for museums, archives, libraries,
,
historical societies, and similar agencies in Florida who
create collection finding aids (guides) according to the En-
coded Archival Description (EAD) standard, version 2002.
The tools on this page permit EAD creators to a) validate
(test) their EAD documents against the rules described in
the EAD Document Type Definition maintained by the
Library of Congress, b) generate a HTML version of their
finding aid from the original EAD encoding, using a XSL
stylesheet maintained for the ARCHIVES FLORIDA
database, and c) derive Dublin Core metadata records
from their original EAD documents.”
28
24
http://www.cdlib.org/inside/projects/oac/toolkit/
25
http://www.archiveshub.ac.uk/arch/dc.shtml#tools
26
http://www.archivists.org/saagroups/ead/tools.html
27
http://www.lib.utah.edu/digital/tools.php
28
http://good-ead.fcla.edu/
67
Archival Management Software
23
• RLG EAD Report Card: “The first automated program for
or
checking the quality of your EAD encoding.”
29
E. EAD Publishing
As several interviewees noted, publishing EAD finding aids
online presents a real challenge, especially to smaller archives
without much technical support. Finding aids can be con-
verted to HTML and placed on a Web server or loaded into an
XML-database/publishing system—operations that are be-
-
yond the capabilities of many archives. Alternatively, archives
can upload the XML file, include a call-out to an XSLT
stylesheet, and use the browser to transform XML to HTML.
Some archives deposit their finding aids with a regional re-
pository such as Online Archive of California (OAC), Texas
Archival Resources Online (TARO), or North Carolina ECHO,
and/or with an international repository such as OCLC’s Ar-
chives Grid. Other archives have adopted XML publishing
platforms that allow searching and presentation of finding
aids, an approach that requires much more technical support
but also provides greater control over data. These publishing
platforms include:
• PLEADE: “PLEADE is an open source search engine
ne
and browser for archival finding aids encoded in
XML/EAD. Based on the SDX platform, it is a very
flexible Web application.”
30
• XTF: “The CDL eXtensible Text Framework (XTF) is a
a
flexible indexing and query tool that supports search-
ing across collections of heterogeneous data and pre-
sents results in a highly configurable manner.”
31
The
California Digital Library uses XTF to enable search
and display of its finding aids, text and image collec-
tions, and other scholarly projects.
• Apache Cocoon: Archives and consortia such as Five
ve
College Archives & Manuscript Collections
32
are using
the open source XML publishing framework Cocoon to
publish finding aids.
• University of Chicago’s Mark Logic XML Database:
The University of Chicago is developing an XML pub-
lishing infrastructure built on MarkLogic
33
a native
XML database. MarkLogic, which is a commercial
product, was selected because it is robust, scalable, and
easy to use. MarkLogic uses XQuery, which supports a
feature called “collection.” Through the collection tag,
29
http://tinyurl.com/6qrzqb
30
http://www.pleade.org/en/index.html
31
http://www.cdlib.org/inside/projects/xtf/
32
http://asteria.fivecolleges.edu/about.html
33
http://www.marklogic.com/
53
Lisa Spiro
24
different collections and archives can be defined, thus
enabling the creation of a multi-institutional
repository. Users can search the whole database or
particular collections. The front end can be built on any
platform and can be displayed in any way the archives
want. The University of Chicago took this approach
because their UNCAP project is multi-institutional and
could be multiconsortial. Such an architecture will give
participants the flexibility to create unique interfaces
for different collections and projects. Chicago’s code
will be available to anyone who asks. Archives that
want to use the software will need MarkLogic, but
there is a free version for a limited number of CPUs
that will be sufficient for small institutions.
II. Archival Management Systems
Archival management systems may be less flexible than EAD
creation tools, and getting legacy data into these systems can
be challenging. However, they offer a number of features that
may lead to greater efficiency and sustainability, such as
support for authority control, reduced redundancy of data,
easy data entry interfaces, the ability to analyze archival data
through the generation of reports, and Web-publishing capa-
-
bilities. Both open source and commercial archival manage-
ment systems are available.
A. Open Source
1.
Archon (http://www.archon.org)
Developed by archivists at the University of Illinois at
Urbana-Champaign, Archon makes it easy for archives
to publish their finding aids online. As its developers
explain, ”Archon automates many technical tasks, such
as producing an EAD instance or a MARC record. Staff
members do not need to learn technical coding and can
concentrate on accomplishing archival work. Little or
no training is needed to use the system, assuming the
staff member or student worker has at least a passing
familiarly with basic principles of archival
arrangement and description” (Prom et al. 2007, 165).
Archon, which is built on PHP 5 and MySQL, enables
archivists to capture information about accessions,
create and publish finding aids online, and export EAD
and MARC. A digital library module supports
presenting digital objects along with finding aids. A
winner of the 2008 Mellon Awards for Technology
Collaboration (MATC), Archon is easy to customize
and provides support for authority control. Explaining
the appeal of Archon, one archivist noted, “Archon is
free and pretty easy to implement without much IT
intervention. … It gave us a quick and easy way to put
collections up on online, let patrons search them, and
Documents you may be interested
Documents you may be interested
