With the launch of the collection online in July 2008, we began with a policy to release only records that had been properly vetted.  The curatorial staff felt that the data released needed to be both accurate and best reflective of the various collections, so in our original spec we created a multi-layered approval process to publish an object.  The vetting process would start in curatorial, allowing them to vet certain parts or an entire record, then the final release would come from our collections staff after an additional once over.  Even though the vetting process worked very well, we were finding that it was taking an awfully long time to publish objects to the web.  For instance, in July 2008 we started with 5168 objects, but eighteen months later we had only grown to 12,598.  While that represents a substantial amount of good data going online, behind the scenes we were seeing long queues of objects ready to release, but hung up somewhere along the way for little bits of final approvals.  In the end, keeping up with the demand of approving records was causing us a great deal of work and getting information out the door was problematic, so we’ve changed course.

At this point, records get published by default and information is added or corrected as we go.  While there are still tons of records that are restricted for various reasons, what we are seeing at this point is much more representative of our holdings. Of course, the release of more records means we had to rethink some aspects of the user experience, so I’m going to run through some of these changes now.

Record Completeness Meter:

One of the most important changes is the visual meter that indicates the completeness of the record.  We want to give our users a very visual way to understand where a record may stand in terms of the overall picture of our data.  As you move your pointer over the meter, the ratings are explained in a tool tip.

Release of Study Images:

Given that we have a lot more records going online, one thing we are lacking are photographs for many of them.  Often our curatorial staff will take study shots with point and shoot cameras just to have something on file for reference.  Internally, we find these shots very helpful and figure that our web visitors may feel the same, so many of these images are being to be released with an explanation regarding the quality.

Comments Overhaul:

We’ve had comments enabled on our object records since the beginning and have received an entire range of responses.  One of the things we noticed is many of the same questions pop up over and over again, so we’ve overhauled the comments area to include a FAQ.  We are hoping this will cut down on some of the more routine questions by putting the information right where people are asking for answers.  Here’s a great example showing why we enable comments on collection objects—you just never know what will come by allowing this kind participation, but we hope the added FAQ will provide better communication all-around.

Browsing, Searching, Sorting:

When browsing, quality records are being pushed to the top of the pile.  When searching, we default to showing relevant records, but users can re-sort the results on demand by relevant or complete.

“The pipeline opens.”

Back in 2005, when we first started talking about digital imaging, I kept envisioning a giant pipeline pouring out images onto my office floor (at 3AM, of course). OK, we’ve got that under control – everything’s now pouring into the DAMS pretty smoothly – AND images are now flowing out to the Museum’s Collection on the Web pages. More importantly, they do so without anybody throwing a switch, copying image files, or writing captions, which brings me to image #2:

“Plays well together.”

It’s not a cliché to say that everything is interconnected. Our DAMS and Collection on the Web projects couldn’t happen without both human and application interactions. The web of collaboration engages people throughout the Museum to the community beyond, from the start of workflow when an image is requested, to the tagging, mashups, commentary, and glossy publications once it’s out in the world. And it’s not just people: our Luna DAMS talks to TMS (our collections management system) and vice versa; our website applications talk to both as well as to content management data sources. Not to speak of Flickr, MySpace, and beyond.

“What’s ‘The Collection’?”

Like most museums, we have a great deal of great “stuff” that extends beyond the formal collection: collections of documentary photographs; special collections in the libraries and archives; scrapbooks, letters, receipts, photographs, and other documents that came to the Museum along with an accessioned object. Curators, librarians, and archivists can’t resist these materials, which help tell the story of the collection.

How the Museum grew over the years and how we presented and interpreted the objects is part of the story that can be told with materials from the Museum Archives: pictures of the building and its galleries; views of exhibition installations; press releases and other historical documents. We’ve already launched our exhibition images on the Web (a project I worked on with HTML babysteps years ago); today’s release of a cross-section of archives and library materials is just the start of offerings that will let you build connections across the collection.

“You’ve got to love data to do this job.”

Building a DAMS isn’t all about the pictures—if that was the case, we could just throw the images up and say “browse.” You have to be able to find the image you want and, if you’re on the working side of the equation, you’ve got to manage great masses of image files. The data-crunchers in the Digital Lab link every image to basic “metadata,” object data comes from TMS, and our dedicated Web community provide tags, item by item. It’s a lot of steps by a lot of people…more on imaging and data workflow in my next post.

Digital asset. The easiest way to think about a digital asset is to simply think, “file.” Most likely an image file for the sake of this discussion, but could be an audio, video, PDF, or graphics file — just about anything in digital format. We call them “assets” to call attention to the fact that it costs money to create them and because they have value to the person or organization that created them. (Besides, DIMS or DFMS just don’t have the same ring as acronyms.) They cost us money to store and back up, too, so we’d better manage them efficiently. If you don’t manage your files, you end up with 5 copies of the same big TIF file scattered around the network, with everybody hoarding their copies because they can’t count on finding them again when they need them.

Management System. When you hit a critical mass of image files (the 10K I talked about yesterday is a pretty effective one to push you into action), you really need a sophisticated database to manage the files and the data that describe both the files (technical metadata) and their contents (descriptive metadata). The system should store and keep track of the master files for you, so you don’t have to set up and manage file storage — there’s only so far you can go with even the most logical folder structure.

You need a good, clear, workable interface where people can work with the images and data–view images, download the size they need for their current project, and upload revised versions. They also need to be able to load their own image files — everybody has a digital camera and a scanner these days.

And then look beyond the individual worker bee at his/her desk, pulling up images for the latest project–when it comes to sending images and data out on the Web, a strong, well organized database is going to make the Web programmer’s work 1000% easier.

And it has to do all of these things without making the network folks blow a fuse. Working on DAMS is going to give you a real sense of what collaboration means.

Most of us have a sense of this with our own image files at home. We started with a handful of files that grew to the point that we were loading things onto CDs, flash drives, and external hard drives. Wouldn’t it be great to be able to find things and share them in the blink of the eye? Get a caption and know who shot the photo and when, without having to get on the phone and use the by-guess-and-by-golly method of data creation? Enter Web services like Flickr and other online services for personal use and the “industrial strength” management systems that we call DAMS for organizations like your friendly neighborhood museum.

You can bet that the administration heard this and more when we pitched DAMS to them. Now we just need to provide proof of the pudding. All in good time. If you want to see more details about what we were and are looking for in a DAMS, click on the “more” link below, but for now, in celebration of the impending 4th of July holiday, here’s my image offering for this post:

Mitchell Tapper (American, born 1953). Fireworks over Brooklyn Bridge, 1983. 83.208.
For this and more great Brooklyn Bridge images, see our digital collection (done without the help of a DAMS, and boy could we have used one), The Brooklyn Bridge and the Brooklyn Museum: Spanning Art and History. Our BB community pool on Flickr doesn’t have anything tagged fireworks — get busy, friends!

Brooklyn Museum: Desired DAMS capabilities

• MySQL, POSTGRESQL or MSSQL database
• use LDAP/Kerberos for authentication against existing Active Directory database
• access to database for data and image export purposes
• ability to map data to and from other databases
• simple and clear method of organizing file storage; automatic placement in imageserver
• ability to program batch data loads and batch image loads with associated metadata
• batch and/or automatic creation of derivatives from a master file at standard or custom file specifications
• ability to handle a wide variety of image file types; ideally also other file types such as doc, PDF, Quark, InDesign; also video such as Quicktime
• highly granular and flexible permissions structure, including
  • individual and group permissions;
  • lock or release individual records and groups of records to individuals/groups/public;
  • control access (view/edit) to metadata at the field level;
  • limit access to specific file types to a specific group (i.e. TIFFs only accessible to limited audience)
• strong descriptive metadata structure, ideally offering
  • templates for standard metadata sets such as Dublin Core, VRA Core;
  • ability to create and/or import pick lists and thesauri
  • set required fields
  • set default values
  • create user-defined fields with permission
  • global update of data with permission
  • create data entry templates
• strong technical metadata structure with
  • ability to record data at the individual file level, including
  • automatic loading of file header data (source camera/scanner; resolution; date; color space, etc.);
  • ability to set session defaults (name of operator, equipment settings, etc.)
• ability to link multiple image files to a single record (i.e. one master image, with multiple derivatives and edited versions)
• ability to link related records
  • multi-part objects-4 views of a single sculpture;
  • a screen that has 3 panels, each a separate digital image
  • image of an object in the collection, a document with text relating to it, a Quark file of wall text
• ability to express a hierarchical structure and the sequence of images within it
  • a book with chapters, sections, and pages;
  • an archival collection with series, subseries, folders, and items
• ability to create ad hoc groupings of assets for projects (i.e. works that will be included in an exhibition)
• ability to create “placeholder” metadata records where images will be added later
• canned and custom output formats for selected images and metadata
  • PowerPoint presentation
  • HTML page
  • Word/PDF document
  • XML output template
• canned and custom administrative reporting
  • data and image load statistics
  • use statistics
  • system reports

Two years ago, I was working in the Museum Archives, where we were busily scanning hundreds, then thousands of images. Once we started approaching ten thousand, it became clear that our bulging Access databases weren’t going to be a long term answer. That’s when I first encountered “DAMS” — and our new goal — a Digital Asset Management System. And so did others around the Museum: our photographers, the rights & reproductions person, our network managers. Others didn’t realize they wanted a DAMS. They just needed images, images, images. Right now!

It’s been a long road (think Wizard of Oz), but we’re finally in the first steps of implementation. Getting there, we talked to everyone around the Museum and to people in other museums who were setting out on the same road, investigated every commercial system out there, scheduled demos, tested some systems, set up a manual system to tide us over as our digital image collections continued to grow — more than 35,000 image of works of art to date. Most of the systems were developed either for big media corporations or for libraries, not museums, so a lot of the things we wanted to do either couldn’t be done or would take big work arounds. Other museums were finding out the same thing, as we discovered in a session at the Museum Computer Network meeting in Pasadena: Get the Picture: Experiences in Selecting and Implementing Digital Asset Management Systems in Museums. This is definitely the first generation of DAMS for museums. They’re bound to improve (I’ve been around long enough to remember when word processing programs required you to insert “dot commands” for formatting, so I have faith in progress…).

So here’s where we are now: we contracted with Luna Imaging for their Insight software, installed and configured it (a process that took longer than we expected), and have started to figure out how to apply the metadata template we designed (CDWA-Lite plus administrative and technical fields) in this environment. Our goal is to import data describing works of art from TMS (The Museum System, our collections management system) and create the image metadata in Luna. This is more complicated than we had hoped, but the good news is that Luna staff have done just this as a “services” project in the past, so we’re confident that our programmer will be able to work it out with the help of support staff.

And the objects in the Museum collection aren’t the only thing we want to get a handle on: we have upwards of 10,000 exhibition views, already online in simple html pages; Library, Archives, and Special Collections materials; views of the Museum building, people, and events; and all the thousands of images curators have collected over the years.

The point of all of this, of course, is to get it out there. The Museum has amazing collections and we’ve gradually started adding more images to the Museum website, both on the collections pages and our Brooklyn Bridge project. The DAMS will make it easier to share more with our online community.

As we speak, Shelley Bernstein and the rest of the IS staff are “laying the rails” for getting our image riches out there to the Web. Over the next months, I’ll try to post regular updates on what we’re thinking, what we’ve accomplished, and where we stand. If I descend too far into jargon, just comment and I’ll clarify. There was a time when I didn’t know what DAMS, metadata, CDWA, Dublin Core, and on and on meant, either.

Being an imaging maven, it would be ironic not to include a picture in my posts, so I’ll try to pick something interesting, beautiful, or amusing each time. Today, since it’s beautiful outside and I’m thinking about heading down to the water when I’m done here, it’s one of our amazing Audubon bird prints: