Media Handling Use Cases

Attach other file types use cases

Image Media viewing use cases

Moving Image Media Handling Use Case

Moving Image uses its CMS's media handling capabilities to add images, audio and video to work records, and to add documents to both work records and acquisition records. Images do not have their own records, but the system does automatically capture technical metadata (e.g. file size), and allows for some descriptive metadata (e.g. title) to be added.

Images, audio, and video can be attached from within an individual object record, or they can be uploaded in zipped batches to a "file space," which is then accessed from within the work record. The mechanism for adding an image, audio, or video file is a simple browse, select and save procedure. The system takes a few minutes to upload and process the image. If the same image refers to two ore more different objects, that image would need to be uploaded twice and attached to both records.

Images can be viewed on any page of an object record, and in search results and some reports. The image viewer includes excellent pan/zoom capabilities.

Adding documents to object or acquisition records is used less, but is still useful. The most common uses currently are adding PDFs of deeds of gift to acquisition records, and adding scans or PDFs of research support materials to object records. These attached documents cannot be viewed within the system; a user has to download them.

The Cleveland Museum of Art

CMS Demonstration Scenarios

How does your system link to multiple external image databases?

Statens Museum for Kunst - SMK

November 22, 2010 - from a conversation with Megan Forbes:

1. Describe the current use of media within your system.

a. All kinds of documents/all formats can be related to a works of art. (.doc, .pdf, .tiff, .jpeg, .bmp, x-ray, IR, moving images, audio)
b. One picture in .jpeg format is uploaded from the system PhotoStation Pro and related to each work of art.

2. Is media stored within your CMS, or do you link to an outside repository/DAMS?

a. Some documents in different formats is stored within our current system, same as a) above.
b. In the system PhotoStation Pro (index server) all pictures are stored.

3. Walk me through uploading or linking to a media asset in your current CMS

a. word document with 2 screen shots
b. IT manager upload from PhotoStation Pro i.e. makes a path from the system to PhotoStation Pro.

4. What are your derivative requirements? (E.g. web-sized, preview, thumbnail, etc.)

It would be nice to be able to scale an image in relation to the artwork's actual dimensions - by some pre-set ratio.
Users need not to know how to map i.e. know where the files is stored.

5. What media formats / file formats do you need to support?

doc, tiff, pdf, jpg, .gif, png, bmp, jpeg + wmf, avi, mpeg4, mov, 3gp, swf, and flv

6. Do you currently use batch upload or image processing?

like 3 b

7. How do you relate media assets to records? Can a record have more than one media asset? Can a media asset relate to more than one record?

Inventory number and tag

8. Do you currently use a DAMS? How, if at all, does it interact with your CMS?

We have no DAMS, in the future we will probably get one.

9. How do you search for media assets?

Search the work of art (number, artist name, title, ...)

10. What metadata do you wish to acquire from the asset on upload or link, e.g. file size, file format, etc.?

Number and link to where it is stored. Metadata in the DAM system

11. Are there current media-related processes and work flows that just don’t work, or seem time consuming/confusing?

Problems with viewers for different formats
We upload manual, should be automatically
If numbers is incorrect the relations is incorrect (fail message)
Not always the newest picture (need version control)

12. What are the strengths of your current system? Where are your pain points?

Too expensive
Not access for all (we want an imagebank = DAMS)

13. Can you send some screen-shots of your interface?

Word document