Databases for storing archaeological or cultural heritage information are not something that one hears spoken about too often despite the fact that they are the backbone of many a project. A good database can improve data accuracy and reduce data entry times, keep the results of your hard work organised and also allow you to analyse or present these results in an efficient way. They’re quite critical in the process of managing heritage information as well, whether that be information about places and objects, documents, oral histories or cultural information. Quite some time ago I promised a post about a heritage database I am developing for an Indigenous community organisation I work with at Weipa in Cape York Peninsula. In this post I thought I would touch on some of the issues that underpin our approach to this as well as why a carefully considered open source approach is in fact fundamental to the ethos of community based management. I’m also seeking collaborators to help advance these ideas.
Community based databases
To my mind, Indigenous community based heritage management sets out to help empower and support communities in managing their heritage places in ways that they see fit, particularly with respect to local decision making processes, priorities and management approaches. This includes the full range of activities involved in heritage projects including:
- project development,
- identification and documentation of tangible and intangible heritage
- significance assessment
- information management (including interpretation).
A well designed heritage database has potential as a tool for community organisations. They can help with making planning decisions and allow people to make greater use of their heritage information for purposes such as community education, tourism, research and so on. The approaches, methods and priorities of communities may vary depending upon specific cultural, historical, economic or social circumstances, however the underlying motive of a community based heritage database is community control, community ownership and self-determination.
Technology can help to empower Indigenous communities who are seeking to take control of their heritage information and to care for and use this information in ways that they consider to be important. However, there are some significant issues that need to be considered and here I list some of those that are at the forefront of my mind at present. I’m sure there are issues that I’m yet to confront and, as always, I’m very happy for further comments and ideas.
1) Appropriate access controls
I am a great advocate of open access in relation to publishing research and disseminating data however there are significant ethical issues with this. In Australia, it is generally acknowledged that access to information relating to Indigenous heritage should be controlled and restricted only to those who have appropriate permissions to access such information. It is critical that cultural protocols surrounding access to information are not only recognised in principal, but built into the fabric of the database itself.
Hence, a community heritage database needs to ensure that access to heritage information is controlled in a way that is culturally appropriate. At the very least, it needs to ensure that access is not open to one and all and, ideally, allow community organisations to decide upon and enable tiered access for different kinds of users.
2) Data integrity
This is a simple point, but an important one. A community heritage database needs to ensure that novice users can not accidentally delete or alter records. In other words, the integrity of the information needs to be maintained.
I once worked for a large (non-Indigenous) corporation whose idea of a heritage database was a spreadsheet accessed across the company intranet. Through user error, a large portion of the spreadsheet was accidentally deleted and it took substantial efforts for this data to be restored. Suffice to say, spreadsheets are not generally the best method of managing large amounts of heritage information.
So in summary, any system that allows data to be accidentally modified is a problem. The tiered access protocols mentioned above would ideally not only control what users can see, but also, who can make changes to records.
3) Simple and low cost
With some exceptions, Indigenous community organisations are often very poorly resourced. They have limited staff, few specialised staff, high workloads, limited cash and generally limited or no IT support. In short, an expensive or highly technical heritage database is not an ideal option.
To my mind, simplicity means a system that is sufficiently intuitive that it can be quickly grasped by someone who can use a computer to access email, browse the web or write basic documents. Simplicity is not a one day training workshop; it is a well designed, intuitive system that can be picked up in a few hours.
Cost effectiveness is another issue. ArcGIS, for all it’s merits, is ridiculously expensive (and doesn’t meet the simplicity clause); a custom designed database is likely to be equally expensive to develop, test and implement. In my view, cost-effectiveness means that costs for development and operation can be easily buried in the budget for a typical heritage project. By making the source code for such a database open source, a developer can be employed to improve and refine it in the knowledge that others will benefit from the work.
In other words, open source shoud be seen as central to the design of a community based heritage database.
4) Open formats
Open formats means that the data are not stored in a format that are only readible by proprietry software. At worst, the system needs to be able to be easily able to export heritage data without any loss of detail.
There are very few software formats these days that I routinely deal with that are not readable by other kinds of software. Even ESRI shapefiles, which were once notoriously difficult to use outside of an ESRI software application (such as ArcView), have emerged as a standard in at least some open source GIS applications.
Nevertheless, it is important that the database does not turn into a silo that locks heritage information into one piece of editing or viewing software.
5) Data Insurance
The database needs to be backed up and fully replicable should something nasty happen, like a fire or theft. One colleague recently suggested a database running on a PC with a network backup would be the ‘safest’ means of providing access to community heritage data. It was proposed that this ‘backed up’ option would be protected from theft, spilled coffee and so on by being physically locked in a back office of a community organisation.
I entirely disagree with this approach from the perspective of data insurance. One PC is easily broken; networks go down and can be very difficult to reestablish for non IT savvy people. External hard drives are notorious for the ease with which they can be dropped. Any system that solely relies upon on site data storage is risky, particularly when in a community organisation where access to computers may not be tightly controlled.
Hosting data on servers that are regularly backed up offsite while providing end user access via a website is the safest option. This also allows for an administrator to be based off site so that maintenance or updates can be made without expensive trips to the community.
6) Community input
One of the critical elements of shaping a community heritage database is that it needs to be able to have new information added by users. This may range from adding annotations to photos, uploading photos and GPS tracks, new site records or management observations. This kind of interaction may be restricted to specific kinds of users, such as community rangers or heritage officers, however the ability to add new information is critical if it is to be useful on a day to day basis for community members.
So there are some of the issues that one needs to get their head around when developing a community heritage database. As I noted, there are likely many more issues that I’m yet to come to grips with and certainly, there will be complexities to each of these points that I’m not yet aware of. Regardless, I think this issue is relevant to many community groups around the world who may benefit by having their own heritage databases.
At this stage, I’m developing these ideas in a very rudimentary form using two different options.
For heritage places, I’m simply using google sites/maps and network hosted KML files. It’s far from an ideal solution and doesn’t meet some of the requirements I’ve outlined here. For example, at this stage users will not be able to add new information and access is controlled by a single password. It does, however, get ‘safe’ information out there for the community group I’m working with, which is a start. The place information is edited and managed in an ESRI geodatabase that I maintain.
Photos, documents and oral histories are being managed by Zotero. At this stage, we’re still adding content and haven’t yet moved a group library to a community workstation. Zotero itself doesn’t allow tiered access, however as I understand it, Omeka does allow this through defined user groups and this may be the way forward for this kind of information. The advantage of Zotero is that students and collaborators can edit and add to the library, which makes lighter work of what is a very slow process.
Ideally, both kinds of heritage information would reside in one system however I suspect the simplest way to achieve this in the short term is a single website with Omeka and some kind of mapping interface. I think if Omeka were able to handle KML files and custom fields (i.e. to suit heritage places) we would have a solution that would resolve many of these issues.
I am very interested to find people who may be interested in collaborating on developing a community based heritage database system that can meet these needs. If you are interested, or know someone who is, please drop me a line using my contact form or via twitter @mickmorrison. I think it would be necessary to obtain funds to develop this further, that is, in order to pay for development time on an open source project.