Pericles project
Promoting and Enhancing Reuse of Information throughout the Content Lifecycle taking account of Evolving Semantics


Software Based Artworks and TMS – challenge accepted

Software Based Artworks and TMS – challenge accepted

On 21 and 22 July 2015 Tate held an internal workshop on Software Based Artworks (SBA) and TMS (The Museum System), a collection management software. This included the Time-based Media Conservation Team, the TMS office and the Research department.


A little bit of background

This workshop was a follow up to a one day training session held in August 2014 focussing on the use of TMS to document Software-Based Artworks. The aim of the initial workshop was to gain knowledge and understanding of SBA especially in relation to using TMS.

As of 2015 there are nine SBA in Tate’s collection. The term ‘software-based artwork’ refers to art where software is the primary artistic medium. These works form complex systems exhibiting a range of dependencies on changing hardware, commercial software, interfaces or technological environments. SBA may include bespoke elements coded by the artist or their programmer, and many involve complex systems that exhibit particular behaviour, such as responding to a visitor or searching for keywords on the internet.

As part of the European research project PERICLES, which aims to ensure that digital content remains accessible in a continually changing environment, Tate is attempting to describe the SBA within the Tate collection, i.e. to capture detailed technical information about the components of an artwork and the digital environments in which they are created.

TMS was initially developed for classic museum objects, like sculptures or paintings. To make it more useful for time-based media artworks such as SBA, Conservation has been working with Tate’s TMS office to SBA adds an extra level of complexity, and so further work is being done to define which information must be kept in TMS, and which information is best kept in other locations.

The workshop was an opportunity to gain hands-on experience by individually using TMS for SBAs. The following questions were addressed:

  • How to capture detailed technical information about the components of an artwork and the digital environments in which they are created?
  • More specifically, what are the SBAs dependencies and relations?
  • How do these dependencies and relations change over time, and consequently, how does one capture such change in the database?

From these questions a discussion followed on the TMS protocol for SBA.

Over these two days we aimed to outline further necessary refinements in the TMS components and attribute-level data entry protocol for Software-Based artworks, with reference to three selected artworks:

‘Sow Farm’ (near Libbey, Oklahoma) 2009 by John Gerrard

‘Subtitled Public’ 2005 by Rafael Lozano-Hemmer

‘Aluminium4’ 2012 by Angela Bulloch

The key aims and outcomes from the workshop include:

  • Creation of a list of attributes that need to be searchable on TMS
  • Defining the minimum information required on TMS to create a useful record for display and conservation purposes regarding an SBA, and the way that this information should be entered;

In plenary we created a mind map to illustrate which attributes will be necessary to include in the TMS. These try to follow the logic of attributes being used for video, and start at the computer level, having a generic description on whether it is Mac/PC or tablet/phone hardware, major Operating Systems, Libraries and Application types. This process also allowed for the discussion of how granular the information can and should be.

  • Coming to a consensus on whether to document the artwork’s computer as a part of the artwork or as a dedicated piece of equipment.  

The consensus was that a computer required to run the software should be made a component of the artwork. This is because in many cases the artworks are supplied by the artists in a form that they have approved and we know it runs as it should. Trying to describe the software and the hardware separately in TMS would be unclear, and for some works, e.g. where scripts are running at the level of the shell, does not make sense.

Participants of the workshop were grouped into 3-4 people, each examining one of the three artworks in detail. A set of guiding questions was supplied, highlighting known issues like: What are the existing components (technically but also in terms of their function) and whether they are already described in TMS; How do components relate to each other; Are any new component names required in addition to the existing terms (Archival Master, Artist Supplied Master, etc.).

Next steps

The list of attributes will need to be discussed in a broader forum.

We agreed that another half-day meeting in September would be helpful to review label and component names, as well as the attributes list created in the workshop.


We are interested in hearing your experience and thoughts on this. Do get back to us with comments, ideas, and views at

Add a comment