Page 18 - Building Digital Libraries

Getting Started

detailed knowledge of how things work. As a result, most things function as
designed, and while the repository is still new, problems are solved rapidly.
After some years have passed, however, supporting and improving the
system become more difficult. The software for any digital repository will
have many dependencies, and it may turn out years later that individual
components are dependent on specific versions of software that are no longer
maintained. This problem can occur with proprietary as well as open source
software. Key players may no longer be available, and critical details will
have been forgotten. Consequently, maintenance and troubleshooting that
were previously simple can become very difficult, and complex operations
such as systems migrations can become overwhelming. Once a system
reaches the point where it cannot be supported properly, all of the resources
in the repository are at risk of being lost.
Maintaining a digital repository in the long term is more complicated
than maintaining an integrated library system (ILS). Over the past few
decades, the ILS market has become relatively mature. Bibliographic, patron,
and vendor data have become more standardized. Future migrations may
be costly and complicated, but they are certainly feasible.
By contrast, digital repositories use divergent and incompatible methods
to store complex information. It is still unclear which architectures will
survive in the long term. It is important to design the repository so that it
is easy to maintain using resources that will be available after some time has
passed. In many cases, this means setting relatively modest goals. Sophisti-
cation and complexity can lead to difficulties, while simple, elegant designs
tend to be more robust.
Before embarking on a repository project, you should ask yourself the
following questions:

Why is the repository needed?

When designing a repository, the most important questions to
answer are why people would use it, who would use it, and what
the impact of that use would be. The repository must identify
the specific needs of specific user groups—all-encompassing
mandates such as storing the output of an institution for any-
one who might need it is not a viable purpose. Is the purpose
to provide access to archival exhibitions, dissertations or arti-
cles, institutionally acquired images for use in marketing and
presentations, datasets with complex structures, or specialized
resources to support specific courses such as allowing students
to interact with scores while they listen to music?
User needs drive the design process. The almost limit-
less possibilities must be reduced to a discrete set of capabili-
ties that will be provided. When determining the purpose, it’s
important not to get bogged down in discussions about what
could be done. Rather, attention must be focused on what will

3