Digital Asset Management's Missing Context of Discussion

9 minute read
David Diamond avatar

Ever had one of those discussions in which neither you nor the person with whom you were speaking seemed to understand one another? No matter how many different ways you restate your points, it’s clear that meaningful communication is not what’s taking place. What goes on between a DAM and a DAM user often feels much like this.

You: “Hi, Tech Support. My computer is running so slowly that I can barely type this message to you now.”

Them: “I am very sorry to hear that you are having problems with your computer and my sole purpose in life at this very moment is to help you in the best way possible. May I start by asking if the computer is currently turned on?”

The equivalent happens regularly between DAM and DAM user. The user asks a question (the query) and the DAM replies (the results) in a way that leaves the user thinking the DAM is stuck in stupid mode.

DAM vendors would say the solution is a new DAM. Information professionals might say you’ve got a metadata problem. DAM administrators, in turn, might insist that what’s really stuck in stupid mode is not the DAM.

The Language of Miscommunication

The real problem is that the user and the DAM aren’t speaking the same language. That is, they lack a shared conceptual understanding of the topic at hand -- the context of discussion. The search results DAMs provide are perfectly legitimate and in accordance with the software’s design -- usually. That is, software tends to do what we tell it to do, even if what we tell it to do doesn’t make sense 100 percent of the time.

As DAM users, we have a conceptual understanding of what’s inside our files. (This is what enables us to instantly recognize “stupid mode” when we see it.) But our poor DAMs can’t read our minds, nor do they have any real understanding of the content in our files, let alone the context in which we’re asking for things.

Consider the following points:

  1. My doctor is an expert in medicine.
  2. I address my doctor as "Doctor."
  3. A friend of mine is also a doctor, but he’s not an expert in medicine.
  4. I don't address him as "Doctor," but I sometimes call him “Dr. Bob” as a nickname.
  5. I need a CMS expert, but I don't care if that person is a doctor. And even if she is, I won't likely address her as "Doctor.”
  6. In the world of doctors, Dr. Dre and Dr. Suess are among the most famous, though neither ever obtained a doctorate of any kind, making them, technically speaking, not doctors at all. It would, however, be easy to classify each as experts in their respective fields.

This is all very easy for you to follow because you’re a human who has a sense of the context in which the terms “doctor” and “expert” are applied here. But now pretend you're DAM software and all this same information has been fed to you as metadata.

In response to the query “CMS expert,” you’re thinking:

You want a CMS expert. But maybe you meant to say you’re looking for a CSM expert, which would mean you need a Cervical Spondylotic Myelopathy expert, who might actually be a doctor. But since you didn’t specifically use doctor in your query, maybe you really did mean CMS. In that case, I can probably rule out doctoral graduates of MIT’s Comparative Media Studies program, even though they are experts in CMS, but I would have considered them if you had used doctor in your query.

What I need to figure out is whether you meant CMS or CSM. Come to think of it, why are some experts doctors, while others aren’t? And why do you call one "Doctor,” but you call the other one "Dr. Bob,” even though he’s a doctor too? And why would one doctor be associated with cats and hats all the time when he’s neither a veterinarian nor a fashion designer? What the hell are you really looking for? I hate you humans. Find your own damned file."

Without some shared conceptual understanding of the “discussion” at hand, it’s unreasonable to think that people and software (or people and people) could ever understand one another.

The Art of Metadata Pollution

So what do we do to provide this missing context of discussion? We have metadata. We study taxonomy, business processes and (if we’re smart), we interview users about how they would like to find things. We think we’re doing this so that our DAM software will be able to “think” more like a human, but in fact, this isn’t what happens.

As we add more and more metadata, we eventually cross a threshold at which point the system becomes unusable. We add terms we think others might use, and then we add synonyms for each of those terms. Then we localize into multiple languages and start the metadata pollution process all over again. Before you know it, your DAM is returning “stupid mode” results no matter what the search.

But what if the DAM actually understood the context in which the user was searching?

It’s unlikely that DAMs will learn to read minds anytime soon, but it’s not impossible for us to endow them with some context of discussion. The trick is that we must stop thinking in terms of files and start thing in terms of content.

"Show me PDF files that were created last month" is a completely reasonable thing to ask a DAM, because it’s a request that takes place in terms a computer understands. But when you start wanting specific PDFs that were created last month, things get more complicated.

This, of course, is exactly why God invented metadata. But as we’ve seen, too much metadata can dilute a DAM’s ability to say no when someone asks for something. And a DAM needs to be able to say no when no is the correct answer.

So let’s take a step back and ask ourselves if the problem is that we’re making files the root entity in our DAMs when we should be making context the root entity. Files are nothing more than the boxes in which we ship and store content -- they are disposable. What’s inside those boxes is what we care about. Do you think the goods stored in Amazon’s giant warehouses are organized by the size, weight and type of the boxes used to store and ship them?

Learning Opportunities

Our DAMs need to be content focused because this is the best way -- perhaps the only way -- to establish a context of discussion that both user and DAM can understand.

To illustrate this, imagine there was no such thing as digital files. Without files, we wouldn’t have file types. If this was the case, there wouldn’t a clear line of delineation between your event photos, the video taken at the event, and the contract documents signed with the vendor who hosted the event -- it would all be just content.

Further, without file types to focus on, the root of your categorization (or association between the content) would become the event itself. When speaking in terms of metadata, you’d be forced to actually describe the event -- it’s date, location, purpose, etc. You wouldn’t need to add metadata tags like “JPEG” or “For Print” or “Watermarked Derivative,” because it wouldn’t even occur to you to describe boxes.

In other words, you would build your DAM using constructs that better reflect the real world.

When someone would later search for “event” content, the DAM would know not to show photos of cats with hats, because those images aren’t associated with an event. There would be, finally, a context of discussion that both the user and the DAM understood.

You can also think of this as an invisible wall between like metadata values that enables a DAM to know when “doctor” should find “doctor,” but not “doctor.” The advent of faceted searching suggests that we’re already starting to see the value of this. But faceted searching asks the user to provide context that the user might not know. The ability to define and provide context must be built into the DAM itself.

More interestingly, context could also enable a DAM to make intelligent decisions with regard to automatic metadata assignments, permissions and processing -- even what types of metadata should be associated with the inbound assets. For example, does your DAM know better than to show a “Duration” field for a Word document? Does it know that a video file doesn’t have a page count? If not, you probably wouldn’t even think of adding an “Event Date” field to a database that contains only a few event assets, because you wouldn’t want to make things messy when other files were displayed. But this type of content-specific metadata is exactly what’s needed to establish a true context of discussion. Without it, a DAM is little more than one file system on top of another.

By telling your DAM that the files you’re about to upload are all part of “Event X,” the DAM would actually know something about the content and purpose of those files. It would know, for example, that a user searching for medical information shouldn’t find those files, even if your event featured a performance by Dr. Dre and your event name was “Meet the Doctors of Digital Asset Management.”

DAM’s missing context of discussion is our own fault. We’re vague and we’re confusing. Half the time we don’t even understand one another and yet we wonder about our software, Why can’t it just know?

Title image courtesy of Jiri Hera (Shutterstock)

Editor's Note: This is the first article by David Diamond. If you are interested in reading more about Digital Asset Management, try:

-- 5 Ways to Maximize Social Media Using Digital Asset Management

About the author

David Diamond

David Diamond has worked in the field of Digital Asset Management since 1998. His book, DAM Survival Guide is a “brain dump” of the knowledge he’s acquired during his years on the front lines of DAM working with users, writing, speaking and conducting webinars.