This week, we’re happy to welcome a special guest blogger – Ralph Windsor, Editor of DAM News and Project Director for Digital Asset Management Consultants, Daydream. On DAM News, Ralph covers everything in the digital asset management industry including trends, opinions, reviews, and of course news. Ralph draws from his many years of experience in IT, software development and DAM to provide exceptional education materials for his audience. In this article, he tackles an important topic for DAM users – metadata models:
This article is about creating metadata models for digital asset management. In simple terms, a metadata model is how you will represent the metadata stored about your digital assets. It is like the blueprint or DNA that will be used each time a DAM user catalogues an asset.
Metadata models define the essential characteristics of your assets in a way that is unique to you and your organisation. They describe a series of key entities or classifications. As well as cataloguing, metadata models can get populated by other activity on a DAM system, for example, workflow to request approval to use an asset. Any activity on a DAM system where users or processes interact with assets takes place within the framework of the metadata model. You will find it touches nearly every element of a DAM implementation – which is why it is important you give it sufficient consideration when planning for digital asset management.
Before you can properly commence implementing a DAM solution, you need to have a reasonable idea of the kind of data you will be storing about assets. For the most part, this will be determined by what users need to search for, but it might also include other information such as reference numbers, for example the SKU (Stock Keeping Unit) of a product if you need your digital assets to be associated with them. The key question when developing metadata models is: what information will our users need to know about each asset to make it useful and relevant to them.
There are some formal methods for designing metadata models, but often a simple list of potential fields is a sufficient starting point and is easy for everyone to understand, irrespective of their prior experience with metadata decisions. For example, this might be a range of metadata entities for a professional services firm:
In addition, some generic items might always get included too:
There will be other fields that are not listed above and some which are not relevant and can be left out. It is very unusual to ever get two DAM implementations that intentionally have an identical schema.
There are many different ways to describe metadata models, but providing all the required information is captured, the simpler they are the better. A list of the key items of data you need to store such as the one shown in the previous section is the starting point, but you will probably want to expand that to define how users will enter metadata. For example, will it be from a fixed list (e.g. a controlled vocabulary) or perhaps free text, maybe numbers or dates. If allowing users to choose from pre-determined selections, will you allow them one option or many? You can record these decisions in a spreadsheet or build simple prototypes using the built-in capabilities of the system. Screen mock-ups of what the interface will look like are another technique.
An issue you can get into when discussing metadata models with colleagues is they may tend to concentrate too much on the content or ‘ingredients’ that might go into the fields. For example, if your DAM system will hold marketing materials about your firm’s products, they might reel off lists of product brand names or model numbers. These are important and keeping records of them is a good idea, but when devising metadata models, you are more interested in the range of potential classifications – the breadth rather than the depth if you want to think about it in spatial terms. Information architects and other DAM experts might refer to this as the ‘schema’ and that description should give you a clue that this about overall design decisions and metadata strategy rather than specific values.
One area where analyzing the range of data that might need to be held in a metadata model is important is in assessing the quantity of different values that might need to be held in a given field. This will assist to determine what kind of interface controls are best suited for it. For example, if every entry is totally different, a free text field would be a good idea. For a small number of mutually exclusive options, radio buttons more suitable. On other occasions, you might use a hierarchical taxonomy which links to a faceted search. The number of items used can make some interface choices more or less appropriate than others.
Read Part 2 of Ralph Windsor’s post about the importance of metadata models for your digital asset management platform and the best ways to continue to execute.