A key part of this discussion is the “why” behind the request.  A person often comes into a library looking for something unknown to them (it makes sense, since if they already knew about it they wouldn’t be asking for help).  In this situation, it stands to reason that you may not be able to articulate just what it is you’re looking for (imagine a person who is not mechanically inclined going to a hardware store).  So if the librarian is able to ask why the patron is looking for the information, it can lead to a more informed interaction, which will often lead to success.  Think of it as contextualizing the request.

If you think about it, this is really just a basic communication skill that has been articulated within the realm of library science to describe an everyday occurrence.  But it can be taken beyond the library environment and applied to everyday conversations.  I mean, why not try to understand someone else’s motivations when you interact with them?  In every situation, whether it’s social or in the workplace, it’s important to understand the other person as fully as possible, and (within reason) it can’t hurt to ask someone for clarification.  It may shake things up a little, but it also may advance the conversation and lead to a breakthrough that you didn’t foresee.

So the next time you find yourself having a conversation, and you’re not entirely sure that everyone involved is working from the same assumptions, think about asking if everyone can agree on what you’re talking about.  I have often found that people are grateful if you’re willing to speak up, since they may have been unclear as well.

This isn’t a difficult concept, and it sounds logical, but I get the feeling that people are afraid of looking stupid, especially at work, and so they are afraid to ask questions.  Don’t be that person — ask, because if you don’t, you’ll just remain in the dark.  And the dark is a scary place to be.

I have a little bit of experience with other DAM software, including Canto’s Cumulus, and Portfolio from Extensis.  If you have ever read the user guides that accompany some of these tools, you can appreciate how dense and unwelcoming they can be.  The user guide for Cumulus is well over 100 pages, and I’m willing to bet that you can’t find too many people who have read the entire thing from beginning to end.  Possibly not even the person who wrote it.  For another take on the issue, see Henrik de Gyor’s post about documentation.

So I’m working on a (hopefully) short, basic version of a user guide for ResourceSpace.  I want to convey the essentials of the system without overdoing it.  I feel that too much information can be just as bad as too little, as it can cause the really important points to get lost in a sea of needless detail.  And since the whole concept of digital asset management is to create efficient ways to locate key information, it is counterintuitive to make the documentation difficult to navigate.  But I’m discovering that writing clear and concise instructions for this system is harder than I thought.  Even with software that is reasonably intuitive, there are lots of little details, and different ways of working, and I want to provide my client with a comprehensive discussion of the key points.  After all, they are the ones who will be using the system, and I want them to feel confident that they can max out its power, and also that they got their money’s worth.

So far I have spent several hours on the document, and every time I feel like I’m getting close to completion I find something that I either a) failed to include, or b) included that I want to take out.  I suppose it may never be perfect, but I’m going to spend some more time with it over the next couple of weeks, in the hope that I can refine it enough to consider it a finished product.  It’s part of the agreement I signed with them when I took the job, and I feel like it will be almost as important as the DAM system itself, because it will make the system much more accessible.  Also, if they hire new staff who will be using the DAM I would like them to be able to hand my instructions to the new person and have it make sense.

Another reason that I’m putting this much time into it is that, as a part of the open source community, I have been considering making this user manual a contribution to the product.  I’m not a programmer and I won’t be able to add much value to the underlying code, but if I can offer up some useful documentation, I will feel like I have done some small part for the good of the community.

So I’ll close by saying that if any of you have any good tips for writing something like this, please let me know.  And, if you are feeling especially generous of spirit and would consider critiquing my work, let me know that, as well.

Instead of thinking about it in those terms, perhaps it’s better to start small and look at a subset of your assets.  Try to figure out what they represent and how expansive you will need the terminology to be.  A key to this process might be asking yourself the question, “Why would I want to find these assets in the future?”  Put it in full sentences.  For example, you might have a video clip of a baseball game, so the idea behind searching for it might be “I’d like to see footage from the Cincinnati Reds 2010 season, in which Joey Votto hits a home run at Great America Park.”*  Now you know you’ll need the team(s), the year, the player(s), the location, and the result of the play.  That’s the beginning of a metadata schema right there.

As you work through your content and pull out additional pieces of information you would like to track, you can start to group similar pieces together.  Obviously for sports footage there will be concepts that translate across most sports, such as the ones mentioned above.  If your content is more diverse, then you will have much more to work through, but you will still likely find patterns in your content and you will start to see categories develop.  This could be the beginning of a rudimentary taxonomy, in which you have top level concepts, and within those top levels you have sub-categories and further breakdowns of the ideas represented by your content.

What you will want to know is that your schema is flexible, and can accept additional concepts going forward.  You will likely acquire or create new content that represents ideas not currently reflected in your assets.  When that happens, you want the ability to insert that new concept into an existing taxonomy with a minimum of effort.  Perhaps it’s an entirely new top level classification, or maybe it’s a sibling to one of your existing sub-categories.  Wherever it fits in with your existing content, you will want to be able to alter the metadata schema accordingly.

This flexibility is what I think of as the modularity of a metadata model.  That just means that you can easily insert new concepts and terms into the schema to reflect changes in your content.  This modularity will also pay dividends on the retrieval end, as it allows your users to combine concepts from your schema in different ways, and thus target their searches more accurately.  This concept is also referred to as faceted classification, or faceted taxonomy.  Briefly, it just means that you classify your content in different, mutually exclusive, ways.  A common example is seen on the Zappos website, which enables you to choose from Men’s or Women’s shoes, colors, prices, styles, etc.  Those bits of information exist independently of one another, allowing you to combine them in an almost infinite number of combinations.  If Zappos starts carrying a new shoe, they have an easy way to insert its descriptive terms into their taxonomy, even if it means adding an entirely new type of shoe.

Hopefully this helps as you begin planning your metadata model.  It’s a challenge, but if you take your time and think about it up front, you’ll end up much happier down the road.  Your metadata needs will likely change, and you can set yourself up for success by creating a schema that is flexible and that can adapt.

*Please note that I am a die-hard Cincinnati Reds fan, and have been for life.

The first conversation was with a former colleague of my wife’s who is now handling sales of a suite of products that supports litigation teams.  One of the services they offer is video deposition support.  This includes taping the deposition and supplying a transcript of the deponent’s testimony with time codes inserted so that the user can easily locate the video footage of the testimony in question.  Depositions are so important in litigation, although you don’t usually see them portrayed in films or on television, because they consist of sworn testimony equivalent to testifying in open court.  Therefore, attorneys need to analyze deposition testimony in preparation for trial.  You can imagine how useful it would be to have the video along with the searchable text of the deposition.

The second conversation was with a married couple at a social event my wife and I attended last night.  The woman is a master sommelier who has a website where she features educational videos about wine.  Her husband handles the videography for this content.  I mentioned that I am involved in digital asset management and explained a little more about the issues DAM tries to resolve and they immediately got it.  They gave the following example of an instance where they could use some help classifying the footage they shoot: Say they are producing a clip about a certain type of wine, but during the video shoot someone brings up a topic that was not previously planned.  This couple described a scenario in which they would like to be able to return to that footage at some point in the future, possibly because they are now producing content about the second subject.  But if they are classifying their footage by the primary topic of the shoot, it is extremely difficult to go back and locate the clip they want to retrieve, because at that point it becomes a question of remembering something that took place weeks, or even months, prior.

So I started thinking about how to apply the concept of a time coded transcript to the wine-related content.  I know this is probably nothing new to people who deal with a lot of video footage, particularly people who work in scripted television or film production where the content is predetermined.  But in situations where the content is more free flowing, like in interviews or casual conversations, you are not working from a script and so you don’t know beforehand all the subjects that may come up.  This same scenario is at work in a deposition (although most attorneys certainly try to guide the conversations as much as possible), or in a conversation about wine.  People will say things without planning them in advance, based on where the conversation leads.

The question then becomes: Is it feasible to have someone transcribe the content for the wine productions and then feed it into a DAM system where the text is searchable?  I like to think that it is.  Perhaps we need to find a court reporter who has a little bit of extra time and would take wine in trade for their services.  After the transcription is complete, of course.

I’m happy to see that someone is putting in the effort to connect DAM-interested workers with organizations that could use the help. Digital asset management is a mature field with established tools, methodologies, conferences, etc., but it seems to me that it has not yet attained the status of an actual discipline, such as accounting, library science, or computer science. There are no real academic programs in DAM, and there is not a certification that an employer can look at to quickly vet a potential digital asset manager. It may be coming, and it may end up being an outgrowth of library and information science (Full disclosure: I have a master’s in library science), or possibly computer science/information technology.

One difficulty for DAM is that it crosses various boundaries: there are elements of computer science (or at least information technology, since software is an integral part of it); library science, with its focus on classification, metadata, taxonomies, etc.; arts and creativity, since creative assets are generally what goes into a DAM system.

Perhaps it is that cross-disciplinary nature of DAM that makes it a slippery concept. It may be difficult for an organization to fully appreciate the need for a DAM solution, or, if they realize the need for it, it may be easy to decide that it is an IT issue and buying the software is the only hurdle to getting a DAM system in place.

As I research digital asset management and connect with experienced practitioners, one of the things I have heard consistently is that the purchase of DAM software does not solve the DAM needs of an organization. It requires planning, many conversations with stakeholders across departments, and constant effort and refinement. And it requires staff dedicated to the success of the DAM system. Without staff to shepherd the system and train the users and maintain the metadata/taxonomy/controlled vocabulary, the organization will face the same problems they faced before purchasing the software, only now it will probably be even more difficult to figure out since it involves a new (and often complicated) system.

Initiatives like Henrik’s are a positive step toward making digital asset management seem more substantive and credible to those (potential) employers who (possibly) see the need for a digital asset management system, and a digital asset manager on staff to run the operation. As someone who is on the outside looking in, I hope that DAM practitioners will look to sustain and grow the industry by seeking out those of us who want to make a contribution. For now, I’ll continue to monitor DAM Internships to see if anything looks promising. If you hear of anything, feel free to pass it along. I’m available.

One of the packages we are reviewing is Cumulus, a fairly common DAM tool. There are already a few separate Cumulus installations on campus, and so it is under serious consideration, since it would be fairly easy to merge those separate installations, if that is the way they want to go. Yesterday a couple of consultants came in to provide a demo of the software and to answer questions that our workgroup may have.

I found the demo to be pretty informative, although in an hour it’s difficult to see everything that a DAM tool will do for you. That must be a difficult aspect of being a consultant in the DAM field — trying to quickly convey the strength of the software you are selling, when it’s capable of doing so many things. I suppose you need to get a feel for your audience and determine the features they will find most useful.

The other package we are looking at is ResourceSpace, an open source tool that I like quite a bit. There is definitely some interest among our group in ResourceSpace (Selfish note: I got to demo my own installation of ResourceSpace for the group, complete with pictures of my dog, so I feel responsible for bringing it to everyone’s attention). One aspect that people appreciate is that there is no cost to license the software. With Cumulus we are definitely looking at some substantial licensing costs.

Another feature of ResourceSpace that resonated with our group, and this one surprised me, is that it’s open source. Even our IT staff is into the fact that it’s open source (for some reason, I thought IT might not be enthusiastic about an open source product — I guess I assumed that their view would be that it means they have to provide all the support). There are a couple of other open source advocates on the team, and I think ResourceSpace is definitely in the running.

All that being said, I feel that the Cumulus consultants did a good job showing us the software’s features. They have obviously done it before, and in fact, they already have a few of our campus departments as clients. It makes sense, as they appear to have a monopoly on Cumulus implementations in the Bay Area.

Now we are supposed to provide feedback to the project coordinator on our view of Cumulus vs. ResourceSpace. In a way, I would like for us to go with ResourceSpace. It’s the DAM software I’m most familiar with, as I’ve been using it for over a year now. But at the same time, there is something to be said for hiring professionals to come in, set up the software, and support it going forward. I’m sure that’s what they would want to hear.

If you have any thoughts on the matter, leave a comment here.

XMP is based on XML, and it is a technology for embedding metadata within the file itself.  That means that the metadata, including rights management and other key bits of information, travel with the file as it moves around.  Pretty important if you want to know where your assets are, who’s using them, and in what ways.

One method of getting XMP metadata into your assets is through Bridge.  Adobe’s Bridge is a tool that comes with the Creative Suite packages, and it serves as a point of connectivity (“bridge”?) between the different applications.  Inside Bridge you can view your assets and their metadata, regardless of which CS application created them.  Bridge comes with some standard metadata schemas built in, such as the IPTC standard, and several others.  But it also gives the user the ability to create their own customized metadata schemas, which becomes increasingly important as organizations implement DAM systems that reflect their own content.  What means something to one company may not mean anything to someone else, so the very nature of XMP and its extensibility is huge.

At first glance the process of customizing the metadata in Bridge was intimidating.  I’m no programmer, so when I see something called an SDK (“Software Developer’s Kit”) I tend to run in the other direction.  But this time I tried to talk myself down from the ledge and set out to learn, if not the entire process, at least the basics.  It helped that I recently met Gunar Penikis, formerly of the XMP team at Adobe, who suggested that learning some of this stuff might help me in my quest to become a DAM person.

So for the past couple of weeks I have been trying to figure out how to develop a custom metadata panel.  Many web searches, several emails, and a lot of head-scratching finally got through to me.  It doesn’t really require programming, unless you count creating XML documents programming (I don’t think XML is the easiest thing in the world to learn, but once you get a sense of its syntax and the use of namespaces, it isn’t so bad).

I have to credit a couple of blog posts for guiding me through this process: 1) this one, from John Beardsworth and 2) this one, from Gunar Penikis (see the third post in the thread).  For me, composing an XML document is a lot easier than learning Flex, especially considering all the resources out there pertaining to XML.  You can often find snippets of XML that you can copy and put right into your own document, which certainly makes things a lot easier (those who can’t code, copy).

What makes this all so useful is that you can incorporate multiple schemas within one custom metadata panel, or you can create multiple custom panels, each with their own schema.  Or you could even create your own schemas and namespaces, complete with metadata fields that are meaningful to you, and that aren’t found in other metadata standards.  Every organization tracks pieces of information that are only meaningful internally, and this method gives you the option to design your own metadata standard, in tune with your own priorities.  This will hopefully make the adoption of the standard easier, as it will feature language familiar to your users, both as they add metadata to the assets, and as they seek to retrieve them from your DAM system.  Of course, you still need to map out how you want that schema to look, but at least you know you’ll have the ability to develop your own metadata recipe, and then alter it over time as your organization’s mission and goals change.  Flexibility is key to any metadata model, as it prevents you from being locked into a standard developed by some external governing body (not that there is anything wrong with the organizations that develop metadata schemas! — they do great work and they get people to converge on some common ideas of how assets should be described).  You want to be able to adjust your metadata model as soon as it becomes necessary, and the development of these custom panels is one method for achieving this.  Try it out.  I think you’ll enjoy doing it.

The nonprofit staff is taking a very relaxed approach to their DAM project, and in most cases, I find that I am waiting on them to get back to me with feedback before I can proceed.  It’s an easy pace to take, and they are very deliberative and willing to discuss various options to get the best system in place.  The gaming company is much different, and I can feel the urgency when talking to my contact there.  Within a week they have contacted me, asked me to evaluate some of the solutions they are currently considering, and to suggest any other options they haven’t already come across.  Now I’ve been invited to sit in on a meeting with the CEO of one of the companies whose software they are reviewing to see if I have any thoughts about their particular solution.  It’s all moving a little fast, and everything that I’ve learned about DAM projects is that haste makes, well, trouble.

Part of the discrepancy between the two clients is no doubt due to their different missions.  One is a nonprofit whose main mission does not revolve around their digital assets.  They are a grantmaking organization and their programs and investments are the main focus.  The DAM system is a way for them to find their images and put them on their website, or to add them to their print publications, and also as a way of creating an archive of the organization’s activities through the years.  The gaming company, on the other hand, is looking to make money off their assets, and it seems like someone may have come across some discussions of DAM systems and their potential for monetary benefit.  Perhaps there is a need to develop a new revenue stream, I’m not sure.  But rushing into a DAM system opens up many possibilities for pain.

Despite their differences, each situation is putting demands on my project management skills.  The nonprofit has a very open mind about their DAM solution and they are looking to me to deliver a “soup to nuts”* solution, in which I find the right software, configure it to suit their content (e.g. metadata fields, searching, etc.), and then populate it with their assets.  The major issue I’m facing is in trying to keep the project moving forward so that we can retain some momentum and enthusiasm for the DAM.  Projects that drift on for too long can lose their sizzle.

On the other hand, I’m tempted to tell the gaming company to slow down a little and to take the time to truly assess what they need.  Since I don’t work there (I have a day job) I’m not sure how much of a voice I’ll have, but I should at least speak out and suggest a more deliberative pace.  I don’t think they have even put together a request for proposals and I don’t get the feeling that they know quite what capabilities their ultimate DAM platform should have.  I just worry that they will rush to adopt a software package that may not work for them in the long term, and then they will find themselves in this exact situation months down the road, looking for a better way of doing things.

So I need to channel my inner project manager.  If anyone has any tips on how I can coax him out of his gopher hole, please let me know.

*See here: http://en.wikipedia.org/wiki/Soup_to_nuts

One issue that has come up is how to incorporate the metadata that is already in use into one system.  There are many things these systems share, such as the names of schools, buildings, faculty, etc., but each DAM implementation has custom metadata fields that apply only to their content.  So how to make sense of it?  Apparently, through metadata mapping and crosswalks.

I won’t venture too deeply into the various metadata schemas, standards, encoding methods, and other (useful? interesting? mind-numbing?) topics that go along with the subject of metadata.  I’ll just say that there are many ways to describe digital assets, and when you have multiple systems, you can pretty much count on the fact that you’ll see a variety of methods.  What is required at that point is to sit down and see if you can make the connections between different fields that hold the metadata.  Here is a helpful chart produced by the good people at the Getty Institute in Los Angeles: http://www.getty.edu/research/conducting_research/standards/intrometadata/crosswalks.html

It will be interesting to see how this plays out, and if it’s possible to unify these systems in more than just a superficial way.  We may find that individual departments feel protective of their custom schemas, or there may just not be a more logical place to put the information than the field it’s already in.  But it will be a good exercise and everyone involved will likely learn something about the other departments who are participating.  As I mentioned in a previous post, metadata is a communications tool, and as we start to learn more about the metadata these departments are using, we’ll learn something about those departments.

I hope I get to take part in this endeavor in some capacity.  I’ll let you know when I break out the Excel spreadsheet and start plugging in values.

The website of the Dublin Core Metadata Initiative says that metadata “articulates a context for objects of interest — ‘resources’ such as MP3 files, library books, or satellite images — in the form of ‘resource descriptions’.” I think that is moving in the right direction, in that it says that metadata articulates ideas about the resources it describes.

That is the aspect of metadata that I feel is most important — its ability to communicate what a particular resource is about, what it contains, or what it’s related to. It’s a shorthand way to represent concepts of varying complexity, to group those concepts together in meaningful ways, and to open up a collection of documents* to a wide variety of users. People who take the time to browse the metadata you apply to a collection can get a sense of what the collection contains, and it will also educate them on the retrieval methods that will work best for them.

Also, imagine that you have a separate group of people dedicated to cataloging your resources, which other users then come along and attempt to locate. The metadata attached to those resources is the shared language that cuts across both groups and helps them understand the collection. The catalogers need to know the terms most likely used during search, while the searchers need to understand the ways in which the catalogers describe the resources. The metadata can serve as a channel between the two groups, enabling them to speak a common language.

A primary goal in implementing a digital asset management system is savings, both of time and of money. If people across the organization aren’t speaking the same language, you probably won’t realize substantial savings in either area. Searchers will be frustrated that they can’t find what they want, and may resort to their own workarounds. The cataloging team will wonder why no one is using the resources they spent all that time describing. And management will wonder what’s so great about this DAM system.

For these reasons, the planning and development of a good metadata schema in advance of a DAM implementation is a crucial step. The ideal situation would be to have users from all of the groups who will be using the DAM system to have a hand in its design. This initial stage of collaboration will drive the metadata toward consensus, and through consensus toward acceptance. And once the metadata schema is devised, it’s also important to recognize that it can (and probably should) change over time, much like languages themselves.

By looking at a DAM system, and its accompanying metadata, as a tool for communication, it may become an easier sell across organizational boundaries. Companies often recognize the need to enhance communication, and blogs, wikis, Twitter accounts, and the like are increasingly working their way into the corporate world. It may not seem like the most obvious benefit of a DAM system, but that doesn’t mean it isn’t a valuable side of it.

*I use the term “documents” to represent any item in a collection, and it can mean textual materials, images, videos, etc.