Skip to content

A word about the way things may turn out with community activity,

It is sometimes useful to talk about community archiving activity as an initiative, rather than the more common term, project. The word "initiative" suggests a continuing process rather than one that needs action for a period of time, after which it ends.

While some community archive activities are indeed projects, it is worth while to think deeper about this aspect, to inform many of the decisions that are necessary in developing and running a community digital archive.

This issue has come to light again recently, and it reminded me of a few examples which show how these two words demonstrate a difference in the way a community archive might work.

The one example that sprang to mind was a community which managed to get some funding for a digital archiving project. For whatever reasons, they chose to place the entire project in the hands of a developer who was from outwith the area. The result, there is no doubt, is a digital community archive. It runs on a computer, and displays various images, documents and even video originating in that community. It was demonstrated to me about a year after the project funding came to an end. In spite of it being just that short space of time, it was easy to note several issues. One was that it was hard for the person demonstrating the system actually to make it work. Once that hurdle had been overcome, the general feel of the system was almost like a marketing website, rather than a deep well containing insights into the soul of the community. That outcome may have been by design, but I make the comment here for obvious reasons regarding this post. And the third aspect was that the archive was now a mere snapshot in time. It was not possible to add more information, at least by volunteers in the community, and so the activity can best be described as a project which was defined, was carried out, and delivered. I would argue, though, that other than during the project itself, it has little long term benefit for the community. Again, the responsible community group may well have had these ends in mind, knowing that they could move on to other things at the end of the project.

By contrast, one community of which I am aware, did indeed, approach matters as a continuing initiative. This led to them making decisions that would benefit the long term access and further storage of digital objects in the community, such as ensuring that the data could be exported or recovered from the system in a widely understood manner, should something untoward occur. In this case, though, the issue was not with the systems or processes, but with group responsible for the archive. Their focus changed, but they still had responsibility for a system that was very much live. The issues, unlike the example above, were neither operational, procedural or technical, but rather, if you like, political. The responsible group then had to make a clear decision regarding the future of the archive, rather than a default position of simply abandoning the work.

It may be argued that there is little difference between the two examples outlined. That may be true, but it does promote different ways of approaching the work. For want of a better description, and to draw on the terminology of the corporate world, one approach merely draws to an end while the other requires an explicit exit strategy.

There is a third approach, which may not fit easily into the points made in this post, but is worth a mention. It may be that a community understands the desirability of a continuing project, but because of abilities, interests or even personalities, the archiving activity becomes one person's sole charge. A variation of this theme is where one person is perceived to be in sole charge. This is where the lines of responsibility and activity can get blurred, an issue that needs careful addressing. Perhaps ideally, constant communication may be maintained with that individual, to let them know that, even if they are doing the majority of the work, the burden of responsibility is not theirs alone, and the bigger picture is being shared.

The Scottish Council on Archives, in conjunction with National Records of Scotland, presented a one day seminar on "Caring for Community Archives" at General register House in Edinburgh on Friday 22nd March 2019.

The day started with short introductions from John Pelan, the Director of Scottish Council on Archives, followed Paul Lowe, the Keeper of National Records of Scotland. One was aware, sitting in the room that was once the Keeper's office, with the portraits by Raeburn of the first Keeper as well as others of Edinbirgh's past nobility, of the significance of these positions. Somewhat trivially, a line from the Michael York film, Zeppelin, set in World War I, sprang to mind: "Destroy a nation's archives and you destroy her soul."

This was followed by a practical session by Peter Dickson, a man whose technical capability and understanding of his role was clear from his desire to share his knowledge. This session was mostly about how to handle and store physical artefacts, mostly paper, and the associated issues around environmental controls. One of the beauties of concentrating on a digital archive is that the specialised needs of physical artefacts are usually only needed briefly, but it was still a useful session.

We were also taken on a short tour of General Register House. This Robert Adam-designed building is now thought to be the oldest purpose-built national archive building still used for its original purpose. Details are on this wikipedia page.

A circle in a square - design detail of the building

After lunch, Dr Alison Rosie, the Head of the National register of Archives of Scotland provided a series of tips for community archives, based on her experience and knowledge. This was followed by Craig Geddes, the Council Records Manager from East Renfrewshire Council, on hos role and how local authority archives can work with community groups.

John Simmons then discussed a frequently misunderstood issue with regard to archives, the role of the GDPR and other privacy directives in relation to community archiving. The most significant takeaway from this talk was that, far from being a constraint to archiving, the GDPR specifically enables archiving to take place.

This was followed by two digitisation and digital sessions, one by Robin Urquhart on things to consider when setting up a project, and one by Tim Gollins, the Head of the Digital Records Unit at National Records of Scotland, talking about the safety and sustainability of digital community archives.

For me personally, the event was of interest to validate or reflect on the work of the last 8 years, as well as an opportunity to meet some practitioners associated with archives and records at a national scale. My Scottish Cultural Studies degree inter-disciplinary project and Honours dissertation looked at the issues between local expressions of heritage against such national cultural activity to see whether the scale of such activities, which on the face of it look the same, do in fact have much in common. So it was of great interest for me to understand a little more of the way the presenters of the seminar worked.

The entire event was skilfully and efficiently managed by Audrey Wilson, the Community Engagement Officer of the Scottish Council on Archives, and was a worth while way to spend a day for anyone with an interest in community archives. Thanks to Audrey and all the speakers.

The four main workstations that are part of the Assynt Community Digital Archive have done their job since 2011, and remain adequate for what is needed in this role.  As with the main archive, part of the reason for this longevity is the use of Free and Open Source software, which is both kind to older hardware and allows us to stay up to date without software costs.

Until recently we have run the long term supported versions of the Ubuntu Linux operating system using the XFCE4 desktop.  This has been updated every three years, but eventually, such updates become lengthy exercises, and little configuration irritations creep in.

Now one of the joys of Free and Open Source software is how modular it all is. I have found through experience that the OpenSUSE Linux system upgrades really well and quickly, and while it does not have long term supported version like Ubuntu, nothing would be lost by trying OpenSUSE as an alternative.  As before, the XFCE4 desktop would be used, so that, to users, everything would appear to be the same.  The exercise in installing OpenSUSE has also allowed us to refresh and check our procedures and security setups.  The standard operating procedure for setting up the workstations is less than page long.

We now have bang up-to-date workstations again, and although this runs on ageing hardware, it remains fit for purpose.

The Assynt Community Digital Archive was set up in 2011 as a long term community initiative.  Readers of this site will know that among the founding principles of the Archive was an adherence to metadata standards and the choice of Free and Open Source software on which to run the Archive.  Among the reasons for this, which have been proven over the years, is that Free Software finds no advantage in attempting to lock users in, the Free Software movement requiring technical excellence as the reason for staying with, or moving to or from, a software package.

The original choice of DSpace was an appropriate one for Assynt's archive, as at that stage it was not clear how the archive would develop, or how the community would make use of it.  DSpace would provide an industrial-strength, proven platform to hold securely any digital item thrown at it.

Another contender was the Omeka system, also discussed extensively on this site.  At the time the Assynt Archive was set up, Omeka was still in its infancy, having been developed from around 2008.   Like DSpace, it adheres to standards, most notably using Dublin Core metadata, as well as providing standard interfaces to export and import data.  Unlike DSpace, which seeks only to be a repository of information, Omeka also allows extensions for creating digital exhibits, and provides mechanisms to view some details of the digital record easier.  There are pros and cons regarding this philosophical difference in approach, which need not be discussed here.

One advantage Omeka has, in practical terms when it comes to managing a digital archive in the longer term, is simplicity of technical implementation.   Omeka is based on PHP and MySQL (or MariaDB) while DSpace is based on Java and Postgresql, requiring a runtime Java environment and a more complicated build and upgrade routine.  While it would be wonderful if Omeka abstracted the database requirement, allowing Postgresql to be used as an alternative to MySQL, there is no doubt that it is easier to run an Omeka instance than a DSpace instance.

Meanwhile, in Assynt, we are gearing up for some additional demands of the digital Archive, as the Coigach and Assynt Living Landscape Partnership (CALLP) has been successful in gaining lottery funding for a series of large projects over the next five years.  It s likely that these projects' data legacies will be met by the Assynt Community Digital Archive, and there was a desire to ensure that a suitable degree of flexibility, to support better the projects' potential requirements, was available to them.  It looked likely that Omeka, now a much more established system, would be a better option.

A series of meetings and demonstrations of the systems with the volunteer archivists gave the go-ahead to transfer one DSpace community to Omeka, to see whether it suited general requirements.  That was successful, and all the DSpace communities and collections were transferred, using import plugins on the Omeka side, and standard export interfaces on the Dspace side.

Among the advantages are a slightly more acceptable, to casual browsers, user interface - Omeka looks more modern and less academic in its standard guise - and the fact that many data types, especially images, are displayed in line with the record.  From a systems architecture point of view, it was decided to provide each existing (and future) DSpace community with its own Omeka instance, so that each community or project can make its own decisions about how look-and-feel, or even about where it wants to host its data.  This approach does make for more repetitive future systems administration, but also spreads any future risk.

As before, all the new systems were built using virtual machines, making the systems less hardware-dependent.  Hardware, in some circumstances for community archiving, is now much less of an issue compared with a few years ago, and Omeka's lighter requirements contribute to this.

It looks as though cross-training to Omeka would be easy, and training new volunteers would be no more challenging than with DSpace.

The change to Omeka from DSpace for the Assynt Archive by no means implies than Omeka is "better" than DSpace, or that Dspace is not fit for this purpose. It simply means that, given this choice of option, for Assynt's current requirements, Omeka looks to fit the bill a little better.

If you want further information about this, please contact me.