Digital Asset Management for Museums Case Study
•Descargar como PPTX, PDF•
2 recomendaciones•7,436 vistas
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.
Recomendados
Recomendados
Más contenido relacionado
Similar a Digital Asset Management for Museums Case Study
Similar a Digital Asset Management for Museums Case Study (20)
Más de Collections Trust
Más de Collections Trust (20)
Último
Último (20)
Digital Asset Management for Museums Case Study
- 1. Digital Asset Management for Museums Pitt Rivers Museum Case Study 27 November 2013 The Queen Elizabeth II Conference Centre, London http://www.collectionslink.org.uk/events/dam2013 Daniel Burt University of Oxford / Sunnymedia Ltd
- 2. My background • Apple Engineer • Filemaker Developer • Medical Sciences work • Publishing work • Collections work
- 3. What is Digital Asset Management? • Method for storing and retrieving digital assets • At a basic level this can simply be an organised folder structure • Often need to link supporting metadata to these assets • In the context of the PRM assets include…
- 4. Digital Images 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.
- 5. Video Files 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
- 6. Audio Files Recordings of events at the museum, ethnographic sound archive, and education recordings Original media, master WAV files from digitisation, and mp3 working copies
- 7. Numbers • 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 images
- 8. DAM @ PRM - Overview • Link to and enhance existing collections management databases • One-to-many relationship between records and digital assets • Centralized archival storage • Delivery to internal and external users
- 9. DAM @ PRM - Main Steps • STEP ONE - Capture • STEP TWO - Cataloguing • STEP THREE - Storage • STEP FOUR - Delivery
- 10. 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 standards
- 11. DAM @ PRM – Image Capture Scans of films and transparencies use Hasselblad scanners Scans of prints done using Epson flatbed scanners Digital images are taken by the museum’s photographer, or by collections management team using DSLR cameras
- 12. 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 records.
- 13. DAM @ PRM – Image Capture
- 14. DAM @ PRM – Audio Capture • Physical media capture outsourced (wax cylinders BL, other media to a local specialist) • Field recordings and local events via digital recorders or direct to computer
- 15. DAM @ PRM – Video Capture • Physical media capture outsourced • Events generally filmed by professional companies • Education team uses Sony ‘prosumer’ DV cameras
- 16. 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 database
- 17. DAM @ PRM – Cataloguing Photos
- 18. DAM @ PRM – Cataloguing Objects
- 19. DAM @ PRM – Cataloguing Audio
- 20. DAM @ PRM – Storage DAM script assigns the asset’s filename, and transfers the archival copy to the museum’s RAID storage. A second step creates JPEG versions of the image and transfers these to the web server that feeds these assets into the internal and online databases
- 21. DAM @ PRM - Storage • RAID (internal access only) – backup to HFS • ‘Live’ assets stored on web server – backed up to HFS • Cloud storage?
- 22. 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.
- 23. DAM @ PRM – Delivery
- 24. DAM @ PRM – Delivery
- 25. DAM @ PRM – Delivery
- 26. 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.
- 27. DAM @ PRM - Delivery
- 28. DAM @ PRM - Delivery
- 29. 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 institutions
- 30. My other current projects Leverhulme funded BACH project and mapping Wellcome Trust funded ALHOM and collaborative online asset creation Two AHRC projects: • Dirhams for Slaves • OCIANA
Notas del editor
- 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