The Pitt Rivers Museum at the University of Oxford was used as a Case Study by Consultant Daniel Burt when he spoke at the Collections Trust DAM for Museums Conference in November 2013. His PowerPoint presentation covers the capture, cataloguing, storage and delivery of images and audio content.
I’m not going to talk about Data Management, database structure and fields and so on, and will concentrate on the practicalities of linking existing databases or metadata to related digital assets. Ideally, your system will be developed from the ground up with this in mind, but often (as was the case with the Pitt Rivers) there will be existing legacy systems storing the data about these assets, so development will be modular – i.e. you are adding a DAM to an existing collections management system.A single asset may have several forms – images may have High Res TIFF versions and smaller JPEGs, videos may have High Def MKV versions and lower resolution mp4s etc.Metadata (library loans, date, geodata etc.) needs to be kept alongside these assets. Could be held in a simple document (e.g. Khalili Collections), xml tables (Pisa), spreadsheets, embedded data (B-WAV) or, in larger institutions, databases of various flavours (Access, MySQL, off the shelf systems such as Museum Plus and KeyEMU etc.). The challenge is to link this data to the assets and to retain this link, even when the assets change.
Are TIFFs really required? You will need a lot more storage space for RAW and TIFF files, and a high resolution JPEG may be just as good for archival purposes and needs a fraction of the space.What resolution should you scan at? 600dpi for prints, 2400/4800dpi for slides and negatives – balance the resolution with time taken to scan and storage space required.As images aren’t embedded in the database, the filename is ESSENTIAL for linking of assets to the database records – easier for sound and photos, where accession number relates to a single asset in many cases (or rather, three variants in the case of photos), but far trickier for Objects images, necessitating the need for the DIA ‘indexing’ database.
Of course, not all assets will be of professional quality – e.g. Louis Sarno’s mobile phone footage etc., but these are still valuable assets
All of these databases were developed in-house using Filemaker Pro in the mid-1990s, they could do with some tidying up (data inconsistencies, non-relational structure, too much freedom for users and could do with stricter data management), but that was not part of my remit – I had to link the digital assets to the existing catalogues, and deliver both the catalogue content and related assets internally and online.
Existing Collections Management System in use, developed in FilemakerUp to three versions of each photo, Raw, Optimised, and RetouchedDisplay all internally, but only the best version externallyInternal and external (online) versions
Existing Collections Management Database in use since the mid 1990s and developed in FilemakerOne-to-many relationship between records and imagesDevelopment of DIA database to manage images and link to the Collections databaseInternal and external (online) versions
Digitisation of tapes, reel to reel recordings, DATs, etc.Development of an internal database to store details and link to audio filesArchival WAVs and mp3 versionsSoundcloud integrationInternal and external (online) versions
ARCHIVAL storage and ACTIVE storageStorage of digital assets:1 – within database itself? – keeps everything together, ease of input (no need to worry about filenames etc.), BUT issues with database size and backups on the University’s HFS2 – Folder structure referencing using Container Fields – would have been easier with Filemaker 12, but we were developing before its release and using FM11 – easier backups, keeps database lean, but if the referenced folder moves and it or its contents are renamed, then connection to the images is lost, it is network-dependent, can result in user error re. naming and saving of files.3 – web-folder storage, delivery via web technologies, and linking to database records by filename – still has drawbacks re. file naming and folder naming, but this was the approach adopted for the systems at the PRM, and the database systems were developed to try to reduce naming problems etc. (particularly in relation to the Objects DIA)NB SECURITY IS VITAL – BACKUPS!! AND HACKER PREVENTION.
Backups and robust storage are essential – these are extremely valuable assets, not least in terms of the time it has taken to create them.
Internal delivery (until last year you couldn’t see a picture of an object within the internal museum objects collections management database – this has ‘transformed’ how staff work at the museum, according to Jeremy Coote), and external delivery (objects and photos online)
The databases run nightly scripts to output individual html pages for all of their records, and these then link to the assets linked to them. The creation of flat HTML pages for each record serves a number of purposes (1) to avoid hacking, (2) to have each record indexed for Google searches, and (3) to provide a unique directly-linkable URL for each record, which can be easily sent to collaborators, or linked to within project blogs etc. (the same applies to assets such as jpegs, mp3s etc. as they all have standardized links). It also allows the museum to use Google Analytics to track web visitors for the site as a whole and for individual objects (e.g. are most people viewing Maori objects coming from New Zealand or elsewhere?)
Multiple image types (O, P, R) per record, with the database displaying the best image available for each recordSome images shouldn’t be shown on the web, but all available images must be available when viewing the database in houseLinks directly to images on PRM Images and PRM Prints to allow visitors to easily purchase prints and/or licensing of photographs in the collectionLinking and web storage of assets means that any editorial changes to the assets are immediately reflected within both the internal databases and online versions and web pages
PRM Sound ArchiveRAID storage for digital assetsAudacity used by research staff for editing and working with the audio filesSound Manager, for batch processing audio files, embedding metadata, processing, and automated storageApache web server running on an OS X server hosts the mp3 versions of the audio filesFilemaker then uses standard web technology to reference these audio files and embed them in the database.
Dropbox for Business = $795 per annum for unlimited cloud storage for up to 5 users e.g. Linking to digital content via web technologies means that not all of your staff need membership, but additional users currently cost $125 per annum.
Also, SHADOW, Social Sciences and Humanities Archives Directory at Oxford
Practical Examples of a DAM Implementation: Daniel Burt
Digital Asset Management for
Pitt Rivers Museum Case Study
27 November 2013
The Queen Elizabeth II Conference Centre, London
University of Oxford / Sunnymedia Ltd
• Apple Engineer
• Filemaker Developer
• Medical Sciences work
• Publishing work
• Collections work
What is Digital Asset Management?
• Method for storing and retrieving digital assets
• At a basic level this can simply be an organised
• Often need to link supporting metadata to these
• In the context of the PRM assets include…
Pictures of Objects and scans of the Photograph Collections, as well as pictures of
events held at the museum
Larger TIFF or RAW files for archival storage and compressed JPEG or PNG versions
as working copies.
Videos of events at the museum, film archive collections, education
videos, and videos for research projects
Original camera recordings, files from Final Cut Pro, and final output
files (mp4s) for delivery
Recordings of events at the museum, ethnographic sound
archive, and education recordings
Original media, master WAV files from digitisation, and mp3 working
• Objects database – 235,000 records
• Photographs database – 175,000 records
• The DIA currently contains over 120,000
images, accounting for about 30% of Objects
• The Photographs database contains about 85,000
images, with up to 3 versions of each
photo, giving a current total of about 250,000
DAM @ PRM - Overview
• Link to and enhance existing collections
• One-to-many relationship between records
and digital assets
• Centralized archival storage
• Delivery to internal and external users
DAM @ PRM - Main Steps
• STEP ONE - Capture
• STEP TWO - Cataloguing
• STEP THREE - Storage
• STEP FOUR - Delivery
DAM @ PRM - Capture
• Future-proofing assets
– Standard non-proprietary file types
• Ensuring high quality assets
– Uncompressed archival versions of assets (WAV
files, TIFFs, AV files etc.)
• Working versions
– Versions for online delivery adhering to HTML5
DAM @ PRM – Image Capture
Scans of films and transparencies
use Hasselblad scanners
Scans of prints done using Epson
Digital images are taken by the
museum’s photographer, or by
collections management team
using DSLR cameras
DAM @ PRM – Image Capture
Many images are scanned from existing slides
(lantern slides, 35mm etc.), and new digital
images are also being taken of objects.
Slides, negatives and prints are scanned and
saved as TIFF files.
The DAM system assigns filenames for these
images in order to link them to the database
DAM @ PRM – Audio Capture
• Physical media capture
outsourced (wax cylinders
BL, other media to a local
• Field recordings and local
events via digital
recorders or direct to
DAM @ PRM – Video Capture
• Physical media capture
• Events generally filmed
• Education team uses
Sony ‘prosumer’ DV
DAM @ PRM - Cataloguing
Photograph Collections are catalogued in the
main Photographs database
Images of Objects are catalogued in the DIA
and linked to the main Objects database
Audio files are catalogued in the main Sound
DAM @ PRM – Storage
DAM script assigns the
asset’s filename, and
transfers the archival copy
to the museum’s RAID
A second step creates JPEG
versions of the image and
transfers these to the web
server that feeds these
assets into the internal and
DAM @ PRM - Storage
• RAID (internal
access only) –
backup to HFS
• ‘Live’ assets
stored on web
server – backed
up to HFS
• Cloud storage?
DAM @ PRM – Delivery
Assets are delivered via
standard web technology to
the internal databases and
their online equivalents.
All images are visible
internally, whereas only
those marked as ‘for web’
are shown online.
DAM @ PRM - Delivery
Delivery via projectspecific websites
Incorporation of assets into
researchers’ blogs etc.
Possible due to
standardization of asset
storage (URLs), allowing for
easy re-use of assets.
DAM @ PRM – The Future?
Storage of files in the cloud would
take away the need for internal
security and backups
Amazon Cloud, dropbox, box, or
other commercial providers?
An affordable and easily
manageable solution for smaller
My other current projects
Leverhulme funded BACH project and
Wellcome Trust funded ALHOM and
collaborative online asset creation
Two AHRC projects:
• Dirhams for Slaves