Low resource environments are characterised by a lack of technical skills, facilities and funding. In such environments, building digital repositories of historical and heritage collections is particularly di cult, exacerbated by the desperate need for digital preservation. This paper analyses design principles for digital repositories and their suitability for lowresource environments. A case study is presented to illustrate how adopting the positive principles in support of low-resource environments can support the creation of a heritageoriented digital repository appropriate to its environment.
While these tools are indeed popular [
There are many reasons for the status quo, but some problems are related to resources and
technical limitations. South African public institutions generally do not have trained technical
sta to manage digital repository systems. Government funding for archiving of heritage also
is limited and many local archives obtain funding from international donors such as the Mellon
Foundation [
This paper argues that the technical architecture of current repository toolkits is not ideal for low-resource environments and an alternative architecture speci cally designed for low-resource environments may be a more e ective solution, especially for the digital humanities and heritage domain where collections are not funded in perpetuity and technical skills and other resources are limited.
In particular, such a solution would aspire to minimalism and a reduction in dependencies, especially on network and data storage, to ensure long term preservation and access with minimal maintenance. The design of such systems is based on a critical analysis of both popular and targeted design strategies that lead to a superset of principles for the design of a modern repository in a low-resource environment.
This analysis and the related principles are presented in this paper, preceded by a discussion of related models and designs, and followed by a discussion of a case study mapped to the identi ed design principles. 2 2.1
One of the earliest works that embodies the notion of a low-resource digital repository was the
creation of Project Gutenberg [
Early models for digital repository systems were strongly in uenced by the emergence of
Web technology and the evolution of software systems from monolithic systems to modular
ones. As an example, the Computer Science Teaching Center [
In contrast, the Greenstone digital library software [
The OpenDL/Diligent [
The Bleek and Lloyd project [
Four design strategies are discussed in detail. These are the design decisions of: the DSpace document repository toolkit; Project Gutenberg's electronic text archive; and the Greenstone digital library system. The simplyCT principles were speci cally developed to support lowresource archives, and thus they serve as a baseline. The comparison with other design philosophies aims to determine if there are additional or implicit design goals that should be included; as well as if there are some speci c design goals that should be avoided as they inhibit the creation of archives in low-resource environments and/or they are irrelevant to the context of heritage/historical archives. 2.2.1
The DSpace design has evolved over many versions, but the core principles remain as they were
originally [
It should be easy for users to deposit items in the repository as deposit of items is a key function of an institutional repository; this is not necessarily a priority for many heritage collections.
The user interface should be based on modern Web technologies; this has evolved over the years, but is generally based on a Java Servlet container and current approaches to creating customisable and generic User Interfaces.
All items submitted should pass through a work ow management system, with customisable roles, actions and steps; this is especially well-suited to large organisations.
Items should be located in collection and subcollection containers that then belong to toplevel community containers.
Items should be assigned globally unique and opaque identi ers on submission, using the Handle system. 2.2.2
The principles underlying the work of Project Gutenberg [
The format of electronic texts is required to be as simple as possible, typically plain ASCII; users of the texts are permitted to create more advanced versions with markup, but it is argued that plain ASCII will reach more users and will outlast other formats and standards.
In order to get the greatest possible bene t for the largest number of users (99%), the project concentrates on texts and services that most users want; thus the focus is never on completeness of collection or esoteric texts and formats.
The texts are themselves produced at low cost and distributed at low cost so cost is never a factor; this means that the sizes of texts should be small, whatever small is within a speci c context and time period.
The texts should be easy to use, refer to, quote, etc. 2.2.3
The key principles stated for Greenstone [
Digital objects of any kind could be imported through the use of con gurable and easy-tocreate plugins.
The system was designed for use in environments with no Internet through the use of a local Web server that is installed on a user's desktop computer.
Search and browse are provided as distinct services for information discovery.
Collections are pre-indexed and processed to enable services, and this process can be easily repeated when changes are made.
Identi ers for objects are persistent across builds so history and log data is not lost.
The system had versions that would work on any operating system, with some limitations (such as that the CDROM version would only work on Microsoft Windows).
Later versions used a Web Services design strategy, where services are located by network service endpoints. 2.2.4
simplyCT
This set of design principles was derived and generalised from the Bleek and Lloyd project [
Only the bare minimum amount of system infrastructure should be needed, to lower the cost of maintenance.
Users should not be expected to conform to system requirements for formats, identi ers, metadata, structure, etc.
File access should be a primary form of accessing data, rather than a Web Services interface.
The data should be accessible whether or not there is a network/Web available, whether through a mediated interface or directly through the lesystem.
Preservation should be as simple as possible, by copying les and directories rather than using a database. A comparison and merging of the various principles discussed in the previous section is presented in Table 1.
Minimalism is explicit in models that aim for simplicity, but not in the other models, where advanced software architectures are adopted for currency. Imposition on users is an issue in DSpace and Gutenberg, where users who submit items must conform to the speci ed formats and structures. Regarding No Internet as a requirement, DSpace does not work except as an Internet service. Simple Preservation is not possible in DSpace, where data for preservation/rescue/backup must be accessed through an API. Most systems allow Any Objects. Most systems do not support exibility in data architecture, so the use cases are limited. Superimposed information is therefore also not possible in those cases. All designs support hierarchical organisation of information. In terms of platform agnostic operations, DSpace and Greenstone support multiple platforms but not as widely as could be possible. Finally, collection building is only possible for designs that allow non-online operation, hence this excludes DSpace.
Design principles that are equally applicable in low-resource and high-resource archives include: standards-compliance, search and browse as features and persistent identi ers.
Some of the principles that guided the design of DSpace in particular have no equivalence for heritage collections and can be argued to be inhibitors in low-resource environments, such as generic Work ow support, which introduces complexity and is often not needed.
This analysis illustrates that a superset of explicit design principles to support low-resource environments is desirable. It also highlights the shortcomings of systems that were designed for other purposes and that do not explicitly take into account the needs of low-resource environments. It is not that these systems are not useful in other contexts; it is just that their design is less than optimal in the low-resource context.
The Five Hundred Year Archive prototype was therefore designed to conform to the identied set of low-resource archive design principles, as discussed in the following section. 3
The Five Hundred Year Archive (FHYA) [
Given that the archive is hosted within a low-resource environment, with a particular shortage of technical skills and funding for ongoing maintenance, a low-resource design is being explored for the digital repository.
The repository system is centred on a set of directories containing digital objects (data/) and metadata (metadata/) . There is then a script that ingests a spreadsheet of metadata by converting the metadata into individual XML les in the metadata directory. A second script then generates an HTML representation of each metadata le using an XML Stylesheet Transformation, with thumbnails and pointers to the digital object; the thumbnails are incorporated into a Javascript slider to display a series of images within a xed space. An indexing system creates inverted les to support searching and browsing via a Javascript-based faceted search engine. All of these operations result in a static website with the full functionality of a read-only archive.
Changes to the collection, such as the addition of comments, are implemented as Web scripts that store the comment, then regenerate the pages for the digital object and the user. Thus, the addition of the comment makes a change to the static repository and there is no dynamic page generation needed.
The technologies underlying the system include: a scripting language optimised for text processing (Perl/Python); XML for storing structured data in at les; stylesheets for transformation of XML (XSLT) and styling of HTML pages (CSS); and a simple Web server to serve pages online for those cases where online access is needed.
Each of the identi ed principles from the previous section can be mapped to the system design decisions, as outlined below:
Minimalism. The explicit aim is to have as little software as possible, with short scripts instead of multi-layered abstractions or agent-based or Web Service-based architectures. Imposition on users. Metadata already exists in spreadsheets so this is used for batch import. Items already contain assigned identi ers and these have meaning to users so these are reused. Similarly, the pre-de ned structure of the collections is maintained. No Internet. All read-only access happens through direct access to HTML les, without any mediation through a Web application. Search and browse services are provided through Javascript applications that read static les. Only contributions to the archive require the use of an online version of the archive and an Internet connection; otherwise the read-only archive can be distributed on o ine media.
Simple Preservation. All data objects are in their original locations and metadata les are created as simple XML les, with associated HTML les generated by a stylesheet transformation. Preserving the original data and metadata requires only copying of the les, while migration can be achieved through transformation of the metadata les. Any Objects. Any data le format accessible through a Web browser is supported; e ectively this is any object since a Web browser will allow a user to download any non-viewable le.
Flexibility. Search and browse services can be de ned to operate over any collection of metadata. User accounts are stored as a metadata collection, and these can therefore be searched and browsed using the same tools as the objects themselves.
Superimposed information. Comments on objects are stored as a superimposed layer of information, in a separate le directory structure, which does not disturb the original objects. When a view of the object is being updated, the comments are drawn into and added to the view, thus creating a seamless experience for the user.
Hierarchical organisation. All data and metadata is stored in hierarchies of directories and sub-directories.
Platform agnostic. Since the system is composed of at les and HTML les, these can be read on any operating system where a Web browser is available. Thus, this is even accessible on all tablets and phones, irrespective of operating system, with no changes to the data or system necessary.
Collection building. All data is pre-processed whenever new items are ingested. Thus, the system is always in a static state with the fastest possible access to items.
Figure 1 shows the front page of the system, Figure 2 shows a page of search results in the Javascript-based search and browse interface and Figure 3 shows a typical digital object page with thumbnails and metadata.
This paper has discussed design principles from prior work that inform the creation of digital repositories and their applicability in low-resource environments. Arguably, many of the principles adopted by current systems violate one or more requirements and environmental conditions, such as the lack of technical skills and resources. An alternate low-resource design is illustrated in the context of the Five Hundred Year Archive, to demonstrate the feasibility of such principles.
Low-resource repositories have very broad applicability. Lowering the barrier to the creation of heritage and historical archives will bene t everyone, not just those in traditional low-resource environments. It can also enable participation on an individual level through the creation of personal and community archives, which is still an elusive goal around the world.
Current and future work includes the creation of additional services, derivation of a reusable toolkit and the application of this toolkit to other use cases to demonstrate its exibility. While it was deemed out of scope for the current project to consider software maintenance, current approaches to software maintenance can also be investigated in future.
The design of low-resource digital repositories explicitly allows for easier migration to other software systems, which are not necessarily designed for low-resource environments. However, while some may think this is the goal, this is arguably a step in the wrong direction as it would take collections that are easily preserved and destroy the very attributes of simplicity that make the collections preservable. 5
Thanks go to the curators of the Five Hundred Year Archive, who have collaborated in the creation of this case study.
This research was partially funded by the National Research Foundation of South Africa (Grant numbers: 85470 and 105862) and University of Cape Town. The authors acknowledge that opinions, ndings and conclusions or recommendations expressed in this publication are that of the authors, and that the NRF accepts no liability whatsoever in this regard.