The archive catalogue which records the contents of our archives is being converted from a system held on a single laptop computer which can only be viewed within Lytham Institute to a new web based system which willow anybody in the world to see what information we hold in our archives. It will also let more than one archivist update it at once whilst searches are taking place.
The software chosen is ArchivesSpace which runs as a web service alongside the LHG web site but is not part of it. It is widely used and appears to have most of the functionality required. The suggested way we use it has been partly based on the way the AKS archive has been catalogued where the that implementation was designed by a professional UK archivist employed for a couple of years to organise that archive. That is based upon the structures normally used in the UK but with some limitations caused by the cataloguing software used at AKS.
Catalogue structure
As a basis for the overall structure the following documents provide a useful overview of how things are normally done.
ArchivesSpace
There are two interfaces to the system, the Public Interface which users use to discover what we have have in the archives and museums and a Staff Interface, which needs a username and password, to add and update information.
Catalogue building blocks
The catalogue information is held in a hierarchy and the first thing to understand are the various units used to build this structure.
Repositories
- In effect the various buildings used to hold the items, as different access arrangements are in place at each location. The software also uses the Repository as unit to control which archivists can manage the records about information held in each repository. So this can also influence the repository structure.For example if there is more than one collection of information in a building managed by different sets of archivists, the software requires us to call them different repositories to enable us to control it in that way.
Then we have
Accessions
- are the bundles of items that have been donated or lent to the archive. The normal procedure at this time is to use an accession form giving the details, any access restrictions or conditions and ask the donor to sign it. This provides a record that is useful if there any concerns about them in the future. We don't currently seem to record accessions in this way but we should start doing so. When somebody provides ietms to go in the archive, the accession record holds the information about the items such as donation/load, access restrictions etc.
Resources
- This is the record of the individual items that are in the archive. These are subdivided into a hierarchy according to resource type. These types are common to other catalogues and have been devised by professional archivists.
Digital Objects
- Nowadays is it very useful to have digital versions of the archived items such as scanned images or transcripts of the text. ArchivesSpace does not provide a place to store digital objects as these are best managed in a Content Management System, and we can use the LHG web site to hold this information. The digital objects provide the mechanism to link from the catalogue to them.
There are few more less important components, but for simplicity these will be left for later.
Resources
Each item we have in the archives is described in a unique resource record. These are arranged in a hierarchy with similar items, such as newspapers, held in their own group. A whole set of these records is known as a Collection. UK Archivists tend to use a different term, a 'Fonds' for this but we are using Collection as that is what the software prefers and it is less confusing for users. Within the LHG repository we have two collections, Documents and Artefacts as these tend to be managed in different ways. The Documents were not split up into multiple collections as the source data was all intermingled in a single Access database. We could add further collections in the future.
Now within ArchivesSpace it seems to have two types of resource, one used to define the Collection record, and within that the ones to handle items in a hierarchical manner which are termed as 'Archival objects'. Now to add a new item in the staff interface we don't use the Create Resource menu item as that is only used to create collections. That is a little more complicated, is not to be used and doesn't achieve what we want, so we just ignore that and use the options within the collections to create new archival objects.
So DO NOT USE Create/Resource!
Resource hierarchy
So now we can look at the types of resource as one of the required fields we need to fill in when defining an archival object is 'Level of Description'. The ones we use are:-
- Collection
- Series
- Sub-series
- File
- Item
A Series is the unit that defines a group of resources, so we have one for Churches, and beneath that a number of Sub-series for the individual churches. For each church we have a number of documents and that could be a File with a number of items within it or something that is a single sheet of paper that we would define as an Item. For the entries converted from the Access database these have been defined as Files as there was no way to automatically make a choice for the 4,000 items brought in from there. The names of the Series and Sub-series that were used from the Access database tend to be the category names within that. It was single level system so some names were changed calling some categories Sub-series to get a better hierarchy.
Publish?
Staff can see all the resources but the Publish flag needs to be enabled for the real users to see it. So we can restrict visibility of some items and some fields within records also have a Publish flag. So we may want to record notes that are only relevant to the archives and hide them from the users. During conversion 'Publish all' was used to make the records visible. For security reasons we may want the flag valuable items as un-published so we don't advertise them to the world.
Title
Another required field is the Title which describes the archival object. This was the only field in the Access system to describe things so it may contain too much information that is better held in Notes fields. It needs to give a good idea of what the item actually contains so helping users decide whether it holds the information for which they are looking. Now for some items a title isn't appropriate so it can be omitted if the Date field has been filled in. An an example of this is newspapers where the Sub-series gives the name and the date is the vital description.
Some of the titles could do with revision to clarify what they actually are. The worst seems to be 'Photo of two mugs', 1990. Nothing else, so it could be one of Phil Stringer & David Hoyle or some crockery lying on the table.
In the Access system the media type was sometimes recorded in the title but this is now held in another field which help make things clearer. In the conversion if the title contained variations of 'photocopy' this has been removed from the title and 'Photocopy' used as the instance type which makes the titles easier to understand whilst still retaining the fact that it is a photocopy rather than an original document.
Dates
Another important field is Dates as when searching for information that date can be important. We can add a number of Date fields as there can be various events of different types. You will usually be entering an Event Date and so this should be specified. A date can be a single one, a pair giving a range, or when an exact date isn't available a description can be entered. Then dates can be an exact day, or we can enter just a year.
As date fields are used when a user searches we need to try and make sure we use them for the dates that the item describes. So whilst we had a date field in the Access system recording when it arrived in the archives or when it was catalogued this has been place in a Notes field so we retain a record of that, but not within a Dates field to avoid searching complications. We also need to be aware of items that may be taken from a newspaper describing an event in the past where the date should be that of the event rather than the date the item appeared in the newspaper. Again it is useful to use a Notes field to save the publication date.
Notes
Notes can be of different types and in most cases Notes/General is the normal one to use to add a fuller description. But we can use a one of the many types in the list for more specialised reasons. Scope/Content is a useful one as it can be used at higher levels in the tree and it appears automatically in the lower ones if that type does not appear in them. So a description about the Antiquarian could be places in the Series entry and that would then appear in each item record giving a more detailed description without having to ad it to each individual item.
Conditions governing Access is another hierarchical one which lets us clearly note any restrictions that may have been imposed by the depositor of the material.
In the Access system we had a Places field the contents of that were placed in a Notes field during the conversion which helps when searching without complicating the Title.
Component Unique Identifier
Each item needs a unique identifier, either written in pencil on the item or maybe on a luggage type tag. So when trying to find it in the container it is much easier to identify it, or when somebody has left it out expecting somebody else to put it way the right place can be found by looking up the identifier in the catalogue. The convention that has been adopted to define identifiers has been devised largely based on that used in the AKS archives which works well. This is:-
<repository code and collection>/<series code>/<sub-series code>/file/item code>
adjusted according to the number of levels we have in the hierarchy. So those in the archives in the Institute start LHA/ for documents or LHR/ for artefacts then numbers for the rest of the components. The final one for the entries copied from the Access system has been the field labelled Accession as that may well be the number already in use, and it does preserve that information.So if something is taken out, perhaps for an exhibition, the label tells us which repository it needs to be returned to and where to put it back.
Now a little frustration is that this field is not flagged as required but we do need to ensure that it is filled in. It does appear in the public interface and within requests to view items. The 'Unique' within the name is also rather a misnomer as there is nothing in place to check that it is. However within our convention there shouldn't be too many items in a sub-series to visually make sure the final number is unique. An item at the top of the 'to do' list (Phil) is to perhaps produce a plugin to check that it is unique and something a little more advanced to automatically create a unique identifier.
To help you see what ids have been used, there is page that shows them. Enter the id of the series you are using into the search box and it will show all the entries starting at that level. Look for the first unused identifier at that level, and enter that.
Instances
Now the bit that relates to the item itself, and we could have more than one copy such as for newspapers. Each is recorded as a separate instance as there can be differences in the fine detail and we may store each instance in different places.
- Type
- For each instance we record the physical type of media as it may be a sheet of text, a book or a whole range of other types. That list is something an administrator maintains and the basic list needs expanding according to what we have. For example 'Photocopy' has been added so that could be removed from the title and we have a record that it is not the original item. The majority of the items added from the Access system have a type of 'mixed materials' as it is rather a general purpose type that covers most things. We need to use more specific types to provide better information about the items. The list of types will no doubt need expanding, by an admin, from the basic set.
- Top container
- This is where we record the box in which it is held. The Container record is where the Location in which to find the box is stored. The container of course may not be a box but something else.
- As we don't actually have containers but only locations in the Access system, a container based on the location name was used in the conversion. Also a problem was encountered in the search interface that returned all other items in the container if we searched for the title of a Series. This was prevented by adding a suffix to the container name for each series. That means we have multiple names for some containers but the first part is the same so there should be no problem finding items and it prevents the search problem. When we get boxes in which to store items the container fields in the Instances will need changing. That will make them easier to use and as there will be far fewer items in each container the problem should hopefully go away.
- There were a few items in the Access system without a location so these were given a dummy container called 'Unknown'. That makes it easy to see which they are by looking at the contents of that container.
Containers
Containers need to be defined before we create Instances using them. They are managed from the menu next to the repository icon. To see them all search for those not Exported to ILS. You then see a list where you can view or edit individual container records and see what is in each one. Each container of course has a name and we should devise a useful naming convention as that is the label we will need on each box.The name shouldn't include the location as over time the storage location could change. There is a field for the container type which is frequently a box. We may need to extend the list of types for other types of container. Then there is the container profile which is again another component we need to manage. The profile in effect records the size of the box and can be used in Extent calculations which record how much space is required to hold the items in the archive.
We have a container type of 'container' which shouldn't be used for new ones. It was added as part of the conversion to identify all those that in effect didn't exist as the they were create to match the locations in the Access system. Once we have proper containers and the archival objects are moved into them we will remove the old container records and finally remove the 'container' container type.
Containers are a little more sophisticated than just being where to record the box id. We have folders within boxes and we use the hierarchy within the Container field to specify the box as the primary container, then folder within the child field. The names used in these fields should not contain the characters Box/folder etc. as these are specified in the Container type and Child type fields.
Locations
Associated with each top level container is a location field. This where we record exactly where the box is stored such as cupboard within room within repository. This only needs to be filled in when a new top level container is defined. If the box is moved to another cupboard then it only needs the location changing in one place.
When we get to the stage of digitising some of the more important items we will add a Digital Object as well as a Container to the Instance for the physical object. For paintings that we hold this would be useful if a digital image was added in this way early on as that makes it much easier to envisage the item. A little more work is required for dealing with Digital Objects.
Agent links
This is where we can add links to people to help with searches for 'what have you got about Freda Bloggs?'. An Agent can be either a Person, a Family, or Corporate Entity so it is a little more sophisticated than just people. When these are added we can go to the Agent record to see which resources have been linked to them and for what reason. When copying from the Access system this was used to provide links to who had donated the items although sometimes the field appears to relate to the content rather than the donator. At the moment the Agents are un-published so they do not appear in the public interface as we may not want to have them visible for living people due to GDPR considerations.
Adding resources
To add a resource we don't use 'Create/Resource' as that is only used to add new collections. Instead we browse an item in the required part of the tree, go into edit mode, and click 'Add child' or 'Add sibling' according to the level at which we want to add it.
If we want to change the series in which items appear, we can select 'Enable re-order mode' and then use one of the 'Move' options. But take care as it seems to be easy to move things into unexpected places without an 'undo' option.To just change the order within the series we select items by clicking the box at the left hand end and drag it to the new place. We can then select 'Before' or 'After' to say exactly where to leave it. It makes it easier for the user if items are put in date order.
It is useful to login to the staff system before accessing the public system. When that has been done, when you look at things in the public interface, an additional icon appears on the screen which lets you go directly into the staff interface to edit that icon. So if you spot something that isn't right, it is easy to fix it.
Administration
Certain actions are restricted to administrators.
Adding users
In order to use the staff interface an admin needs first to create a username and password for the archivist to login. Permissions are set to control which repositories they can work on, and there is a limited level of configuration of the levels of changes that can be made. So normal archivists see less complicated screens making the job easier.
ArchivesSpace Training sessions
The way to use ArchivesSpace has been described in a number of videos and these were very useful in designing the LHG system. They do take a long time to view and don't always quite match our implementation but do provide a very useful level of training. Session 2 is the best starting point at the moment. These are too technical for most of you so best avoided and only worth viewing once you are an expert.