Making computers understand the concept of an ‘object biography’

We’ve gone a bit quiet over recent months on the progress of our work with Historypin, so I thought it was perhaps time for an update on what we’ve been doing behind the scenes.  If you go to the MERL Historypin channel you will be able to see some of the first objects we have pinned to the map.  Most of these are from the Berkshire village of Bucklebury, but there are also some wagons and ploughs from a wider geographic area.

Inevitably, these first trial uploads have thrown up some technical issues that we hadn’t considered.  When we export data from our own Adlib database, we want to minimise the alterations made to that data before it is then uploaded to Historypin.  The fewer changes we make in that intermediate stage, the more manageable and future proof the whole process becomes.

Initially, we had exported our data into a CSV file (it stands for ‘comma separated values’, apparently).  When we looked at the resulting pins on Historypin, we realised the limitations of this approach.  Whilst most of our objects have only one known ‘place made’, ‘place used’ or ‘place acquired’ (if at all), there are some objects for which we have more complete object biographies, where we know perhaps two or three previous owners.  Similarly, there might be a composite object, with multiple parts made by different people.

Fork - 60/290

This fork (60/290) was made in multiple places. Its handle was made by Bucklebury handle-maker Harry Wells, whilst the metal head was made by a local blacksmith.

Because of the way they work (something to do with being ‘comma separated values’) CSV files can only export one occurrence of each database field.  We had to find a new method of exporting which would enable us to pin objects to all the places with which they are associated.  We are currently trialling the use of XML files as an alternative.  We’ve yet to try uploading to Historypin in this way, but our first tests show that we can at least export multiple occurrences using this type of file.  So, we’re making progress.

Another problem we’ve been working through is trying to find a way to export latitude and longitude data for associated places.  Focussing on place has already necessitated the addition of extra fields to the database – initially we recorded latitude and longitude in the notes field of the thesaurus records, but specific fields for grid references have since been added, and we now record the information there.  Due to the way the database works, though, we were initially unable to export the latitude and longitude for places added as ‘associated places’ (rather than as a ‘place made’, ‘place used’ or ‘place acquired’).  This problem has since been solved by extra changes to the databases, but it highlights how projects working with technology such as this require a significant amount of technical work behind the scenes to get museum data online.  It is not always just a case of looking at the accession files and then bunging it all on a computer.